Hacker News Reader

Comment by davidjgraph | Hacker News Reader

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.

View on HN

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-amaz...

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.

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.

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/

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.

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.

Reply on news.ycombinator.com