10 ms·

I'm not sure I understand your question. If you mean: I have an authentication service, Auth.com, and I would like the users to be able to enter their user nam

by Swannie 16y ago

I'm not sure I understand your question. If you mean: I have an authentication service, Auth.com, and I would like the users to be able to enter their user name and password on AnotherSite.com, how do I stop javascript on AnotherSite.com hijacking their submission to Auth.com? Then the short answer is, you can't. That is why all services redirect you to their own login page, where they control the HTML (and can audit to be sure that no one has injected code into their site). What Facebook does is usually in an iFrame, which accesses the user information relatively securely. Any interaction more complex than a "like" is generally redirected via facebook.com (e.g. any permission grants). iFrame's used to be riddled with flaws, but I believe they are considered fairly safe these days. Go educate yourself on the protection of XSS and CSRF/XSRF, and you'll be able to answer all of your own questions.

EGreg 16y ago
No, that's not what I am asking. And I am very familiar with how to combat XSS and CSRF, having written a PHP framework that does it for you out of the box, among other things (http://phponpie.com http://phponpie.com) I am asking another question. If I am operating an OpenID provider, say Auth.com, and CoolStuff.com uses me to authenticate a user, then they can use that session. Great. But now let's say I operate an OAuth provider, and it releases this user's uid, first_name and last_name. What measures does facebook and other OAuth providers take to prevent the uid, first_name, last_name and other data from just being changed by the user in javascript, before being posted to the CoolStuff.com servers, after they have been obtained using Javascript ... such as FB.api('fql.query', ...)
- kertap 16y ago
  If I understand the question correctly, you are asking what's to stop someone from changing the UID, etc when the user is redirected from auth.com to coolstuff.com? From my understanding of OAuth, when the uid, first_name and last_name are sent by auth.com it also sends a cryptographic hash of everything. So if you change the uid, you would also have to change the hash and you can't change the hash without knowing the shared secret that the auth.com and coolstuff.com have decided on prior to your request.
  - EGreg 16y ago
    so what you are saying is that coolstuff.com's servers must always look for a signature from auth.com when they are accepting user data, they cannot trust the user input. That makes sense. So does facebook connect, google, etc. have this? I assume not.
    - Swannie 16y ago
      Well if you protect against CSRF you should be checking a nonce for all form submissions anyway. This doesn't appear to be all that different to me. I'm intrigued now, I hope someone can give details!
      - sawyer 16y 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.
        EGreg 16y 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.
        sawyer 16y 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).

by Swannie 16y ago

EGreg 16y ago

No, that's not what I am asking. And I am very familiar with how to combat XSS and CSRF, having written a PHP framework that does it for you out of the box, among other things (http://phponpie.com http://phponpie.com) I am asking another question. If I am operating an OpenID provider, say Auth.com, and CoolStuff.com uses me to authenticate a user, then they can use that session. Great. But now let's say I operate an OAuth provider, and it releases this user's uid, first_name and last_name. What measures does facebook and other OAuth providers take to prevent the uid, first_name, last_name and other data from just being changed by the user in javascript, before being posted to the CoolStuff.com servers, after they have been obtained using Javascript ... such as FB.api('fql.query', ...)

kertap 16y ago
If I understand the question correctly, you are asking what's to stop someone from changing the UID, etc when the user is redirected from auth.com to coolstuff.com? From my understanding of OAuth, when the uid, first_name and last_name are sent by auth.com it also sends a cryptographic hash of everything. So if you change the uid, you would also have to change the hash and you can't change the hash without knowing the shared secret that the auth.com and coolstuff.com have decided on prior to your request.
- EGreg 16y ago
  so what you are saying is that coolstuff.com's servers must always look for a signature from auth.com when they are accepting user data, they cannot trust the user input. That makes sense. So does facebook connect, google, etc. have this? I assume not.
  - Swannie 16y ago
    Well if you protect against CSRF you should be checking a nonce for all form submissions anyway. This doesn't appear to be all that different to me. I'm intrigued now, I hope someone can give details!
    - sawyer 16y 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.
      - EGreg 16y 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.
        sawyer 16y 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).