[jbert]

So - there has to be some trust to the client, unless the resource is public (or locked down with end-user creds).

In this case, some kind of creds need to go into the app, right?

So the best practise is simply to make those some creds which: 1) have limited privileges (e.g. just access one S3 bucket) and 2) can be centrally revoked (requiring app update for everyone?)

I've read the link on the amazon Token Vending Machine approach, but I still don't understand why that is better.

If I have the embedded creds to get a token from the TVM, and that token allows me to access an S3 bucket, how is that more secure from using limited IAM creds which just allow direct access to the bucket?

In both cases:

- the creds can be revoked centrally

- possession of the embedded creds allows access to the S3 bucket (either directly, or by fetching a token first)

[dmpatierno]

STS (Security Token Service) can generate credentials with much finer-grained control than just access to a whole bucket. You can require user authentication, do rate limiting, and set expire times. To allow a client to upload an image, for example, you can generate credentials that only grant privileges to a specific file location. It's much better than embedding master IAM credentials in a client.

[jbert]

Thanks very much for that.

In terms of comparing the two approaches, I can see that if you are granting different creds based on a user auth, an STS is useful to grant temporary creds limited to a subset.

I'll need to look up the details of how much more fine-grained the STS tokens are than the IAM creds to see how much difference there is in the anonymous case.

[logn]

I don't get why this is necessary. Is there no server backend in these cases? I don't do much mobile development, but I would just generate a random token and register that with my server, like a cookie.