5 ms·

It's a library helping devs move to a fully client-side model.... that requires a server for auth. I must been missing the intended use case. Happy with the Go

It's a library helping devs move to a fully client-side model.... that requires a server for auth. I must been missing the intended use case. Happy with the Google Drive and Dropbox equivalents, this isn't something that we'll be adding to that set.

williamcotton 13y ago
What is wrong about this model? To me, one owns a domain, and ownership and trust in that domain is a source of authority. That authority will authenticate users, provide them with a set of credentials, and those credentials can then be used to write or store data. All that this method does is allow for the rest of the logic to be anywhere... client-side or server-side.
- davidjgraph 13y ago
  Because if you look at how Google Drive and Dropbox do it, they enable you to run fully client side and use their storage. I can serve the whole thing statically, it's far simpler architecturally and saves a ton of CPU and bandwidth costs. From what I'm reading, you can't do this auth fully client-side.
sha90 13y ago
You don't need a server for auth, that's what web identity federation[1] is for. [1] http://aws.typepad.com/aws/2013/05/aws-iam-now-supports-amazon-facebook-and-google-identity-federation.html http://aws.typepad.com/aws/2013/05/aws-iam-now-supports-amaz...
- davidjgraph 13y ago
  In the flow picture at the bottom, the STS looks like a server to me. What I'm saying is the auth flow still seems to require a server to act as an indirection to the real auth server. But if Amazon provide that part for us, great.
  - sha90 13y ago
    It's not just Amazon providing this-- there is Login With Amazon, but there is also Facebook and Google that act as identity providers. Unless I'm mistaken, this is how Google's storage APIs work too, by using OAuth/OpenID to get an access token that can then be exchanged for keys.
    - jeffbarr 13y ago
      Here's a sample that will let you authenticate using Facebook and then upload content to S3: http://aws.amazon.com/developers/getting-started/browser/ http://aws.amazon.com/developers/getting-started/browser/

williamcotton 13y ago

What is wrong about this model? To me, one owns a domain, and ownership and trust in that domain is a source of authority. That authority will authenticate users, provide them with a set of credentials, and those credentials can then be used to write or store data. All that this method does is allow for the rest of the logic to be anywhere... client-side or server-side.

davidjgraph 13y ago
Because if you look at how Google Drive and Dropbox do it, they enable you to run fully client side and use their storage. I can serve the whole thing statically, it's far simpler architecturally and saves a ton of CPU and bandwidth costs. From what I'm reading, you can't do this auth fully client-side.

sha90 13y ago

You don't need a server for auth, that's what web identity federation[1] is for. [1] http://aws.typepad.com/aws/2013/05/aws-iam-now-supports-amazon-facebook-and-google-identity-federation.html http://aws.typepad.com/aws/2013/05/aws-iam-now-supports-amaz...

davidjgraph 13y ago
In the flow picture at the bottom, the STS looks like a server to me. What I'm saying is the auth flow still seems to require a server to act as an indirection to the real auth server. But if Amazon provide that part for us, great.
- sha90 13y ago
  It's not just Amazon providing this-- there is Login With Amazon, but there is also Facebook and Google that act as identity providers. Unless I'm mistaken, this is how Google's storage APIs work too, by using OAuth/OpenID to get an access token that can then be exchanged for keys.
  - jeffbarr 13y ago
    Here's a sample that will let you authenticate using Facebook and then upload content to S3: http://aws.amazon.com/developers/getting-started/browser/ http://aws.amazon.com/developers/getting-started/browser/