Hacker News new | ask | show | jobs
by sawyer 5640 days ago
OAuth 2.0 login providers use an access token that is user specific for all subsequent interaction.

For example, with Facebook, once a user has logged in and given Application X permission to access their details, FB will send the user's id, name, etc. (whatever data the user has granted access to) along with a unique access token. The next time, and every subsequent time Application X wants to access the FB API on the user's behalf it is required to send that access token. From javascript you might be able to change the token, however, Application X's next interaction with the FB API will fail if the token is invalid and there is no way to derive a token value from a FB user's id.
1 comments
EGreg 5639 days ago
That's it? That sucks.

I don't have to change the token. I just have to change the data given by facebook (including the uid) before the website's dumb javascript uses it in a post back to the server. Since it's not signed by Facebook, how can the website's server trust the uid? Never trust your user input.

link
sawyer 5639 days ago
The user logs in on Facebook's server, there is no opportunity to change a uid. Facebook might return the logged in user's id, however that's not useful, the only way to interact with their API will be with the access token (which only grants you access to the logged in user's scope).
link
EGreg 5639 days ago
I am not talking about interacting with their API.

Facebook returns a uid. When the user takes an action, this uid is sent to the server. The server trusts the uid, and saves this action as taken by the user identified by this uid.

And let's say it's not the uid. Let's say it's the user's name.

It trusts the user input basically. But it should probably be getting it directly from facebook, or in a signed structure, right?

link