[oauth] Re: Authentication API protected with OAuth
Most of the major providers that I know use SSL behind netscalars too for their login servers. Usually netscalers persist the connections with the origin servers so there is still huge performance improvement while securing the data in transit in the internal network. Of course passwords still have to be sent over post not just to get them off of server logs but to prevent the browsers from storing it in users history. -Praveen On 1/30/09, George Fletcher gffle...@aol.com wrote: Agreed. I don't think this solution works for everyone. Though from that post it seems that unless the site is using SRP the password is going in clear-text over the wire (SSL) for sites that store salted hashes. (I just used Live HTTP headers to verify a major online service provider and this is the case. The password is in clear-text over SSL) If the site uses something like a netscaler to offload their SSL, then the clear-text password is in the clear inside the company's network. Hopefully, most sites using this scheme make sure the password is specified in a POST to ensure it's not being stored in clear-text in the server's log files:) Thanks, George Brian Eaton wrote: On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher gffle...@aol.com wrote: The request is only valid if the receiving authentication system can generate the signature using the password for that user. Lots of authentication servers can't do that, because they do not keep a clear-text version of the user's password. Instead they store a salted hash. I love Thomas Ptacek's summary of password storage schemes: http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ -- Chief Architect AIM: gffletch Identity Services Work: george.fletc...@corp.aol.com AOL LLC Home: gffle...@aol.com Mobile: +1-703-462-3494 Office: +1-703-265-2544 Blog: http://practicalid.blogspot.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Authentication API protected with OAuth
The PIN could actually be delivered out of band at the time of authorization (via SMS, for example). I agree that more shared secrets doesn't necessarily help things, but it's like FriendFeed's Remote Key... I'm not a huge fan of it since it puts the burden on the user to remember yet another SS, but insomuch as a PIN could enable a smoother desktop experience, as you've described, it might be worth prototyping at least. Chris On 1/29/09, George Fletcher gffle...@aol.com wrote: Yes, using a PIN instead of a password would work as well. The general principle is that the user is using a remembered shared secret to sign the request to prove they know it. The OAuth signature mechanism provides a convenient way to do the proof. One interesting question about your PIN idea is whether a PIN should be associated with a Consumer via some other, out-of-band provisioning process (i.e. the PIN is specific to the Consumer token). Or whether a PIN should be associated with a set of generic authorization capabilities. This is more useful if a user has only a few identities and a central way to manage authorization. In the current model of each SP also being the IdP for it's service, using a PIN model just increases the number of shared secrets the user has to remember. However, it does provide a way to authorize limited capabilities that passwords don't. As for software asking for passwords, I believe this has a relatively narrow scope. For instance the AOL desktop client asking for the AOL password. I agree that we should move away from the current model where Facebook asks for the AOL password when finding friends. Thanks, George Chris Messina wrote: Ah ha. I get it. That makes sense -- though it does seem like the goal should be to move away from asking for usernames and passwords. This, however, speaks to my concept of an account pin, where you could authorize desktop apps with an easy-to-remember pin that doesn't give you full account access, but only allows you to validate that you own the account. So you would have a full access password (seldom used) and an identification PIN -- almost like a security question (we know how well those work). So instead of a user inputting their username and password, they would input their username and PIN, and the PIN would be used to sign the request, proving to the SP that it's the right user -- and then the SP would provide the access token. Is that a similar but equally effective approach? Chris On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher gffle...@aol.com mailto:gffle...@aol.com wrote: Thanks for this history Chris. I remember it still being API authentication in the first drafts of the OAuth IPR document; because it was one of my comments on the doc:) Here is an example usage. Again, this is more about leveraging the OAuth signature mechanism than trying to represent the whole OAuth flow. Currently at AOL we have a clientLogin API that allows a client (think destop app or mobile device) to authenticate a user and then access services at AOL. Basically, the authentication credentials are exchanged for a token that is used subsequently to access the APIs. The user's credentials are only passed to the AOL authentication service, over SSL, for validation. With the method suggested, the same validation could take place but the password would not be present in the request. Instead it would be used to sign the request. The request is only valid if the receiving authentication system can generate the signature using the password for that user. The successful response of such a request would be the API access token currently used. Another possibility (the example from the initial discussion) is using this mechanism with TLS in order to return to the client a SAML Holder-of-Key Assertion. This is the same concept of exchanging one set of credentials for another credential (in this case a SAML Assertion). I realize that there are security issues with allowing a client or API based authentication mechanism, but there are certain cases where it provides a better user experience and the user is comfortable trusting the application/device. Thanks, George Chris Messina wrote: Hmm. Historically the separation came from the way the communities grew up actually. There were thoughts initially to make OAuth and extension of OpenID but because I was wary of the politics within the OpenID community, I pushed for keeping OAuth completely separate and avoid having to do anything with authentication (so that it could be used with OpenID, but would have its own adoption curve). The typo on the homepage was probably my fault, since, being the identity n00b, I didn't realize the difference
[oauth] Re: Authentication API protected with OAuth
On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher gffle...@aol.com wrote: The request is only valid if the receiving authentication system can generate the signature using the password for that user. Lots of authentication servers can't do that, because they do not keep a clear-text version of the user's password. Instead they store a salted hash. I love Thomas Ptacek's summary of password storage schemes: http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Authentication API protected with OAuth
Yep. The entire authentication/authorization discussion is sadly muddled. The OAuth/OpenID hybrid proposal is adding to the confusion. Sometimes I feel like we (people who have interest in the two concepts) maintain there is a difference to justify standards' existence, even if it's largely an academic difference with no pragmatic real meaning. Other times it feels okay that they should be separate. Just one of those things, I guess. For the longest time oauth.net claimed OAuth was for API authentication and no one really noticed. The only thing worth being very strict about, IMO, is identity and authentication. Never the twain should meet. It's HMACs all the way down anyway :) Hans On Wed, Jan 28, 2009 at 12:02 PM, John Kristian jmkrist...@gmail.com wrote: Yes, a digital signature can be used for authentication. SSL/TLS is one example. OAuth specifies some signing algorithms that could be used for the purpose. But it seems dangerous to extend OAuth to do authentication as well as authorization. Better for OAuth to focus on doing one thing really well. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Authentication API protected with OAuth
Hmm. Historically the separation came from the way the communities grew up actually. There were thoughts initially to make OAuth and extension of OpenID but because I was wary of the politics within the OpenID community, I pushed for keeping OAuth completely separate and avoid having to do anything with authentication (so that it could be used with OpenID, but would have its own adoption curve). The typo on the homepage was probably my fault, since, being the identity n00b, I didn't realize the difference until after I went home from the DevHouse where I put up the homepage after a couple beers. It didn't change because (apparently!) no one else seemed to read it that closely. Funny how these things develop -- not always out of explicit intention, but just because of the time allotted to get the thing out the door! ...as for your idea, George, I think I get it, and it sounds interesting. Can you give a concrete example where that could be used today? Chris On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist h...@granqvist.com wrote: Yep. The entire authentication/authorization discussion is sadly muddled. The OAuth/OpenID hybrid proposal is adding to the confusion. Sometimes I feel like we (people who have interest in the two concepts) maintain there is a difference to justify standards' existence, even if it's largely an academic difference with no pragmatic real meaning. Other times it feels okay that they should be separate. Just one of those things, I guess. For the longest time oauth.net claimed OAuth was for API authentication and no one really noticed. The only thing worth being very strict about, IMO, is identity and authentication. Never the twain should meet. It's HMACs all the way down anyway :) Hans On Wed, Jan 28, 2009 at 12:02 PM, John Kristian jmkrist...@gmail.com wrote: Yes, a digital signature can be used for authentication. SSL/TLS is one example. OAuth specifies some signing algorithms that could be used for the purpose. But it seems dangerous to extend OAuth to do authentication as well as authorization. Better for OAuth to focus on doing one thing really well. -- Chris Messina Citizen-Participant Open Web Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable[X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Authentication API protected with OAuth
Thanks for this history Chris. I remember it still being API authentication in the first drafts of the OAuth IPR document; because it was one of my comments on the doc:) Here is an example usage. Again, this is more about leveraging the OAuth signature mechanism than trying to represent the whole OAuth flow. Currently at AOL we have a clientLogin API that allows a client (think destop app or mobile device) to authenticate a user and then access services at AOL. Basically, the authentication credentials are exchanged for a token that is used subsequently to access the APIs. The user's credentials are only passed to the AOL authentication service, over SSL, for validation. With the method suggested, the same validation could take place but the password would not be present in the request. Instead it would be used to sign the request. The request is only valid if the receiving authentication system can generate the signature using the password for that user. The successful response of such a request would be the API access token currently used. Another possibility (the example from the initial discussion) is using this mechanism with TLS in order to return to the client a SAML Holder-of-Key Assertion. This is the same concept of exchanging one set of credentials for another credential (in this case a SAML Assertion). I realize that there are security issues with allowing a client or API based authentication mechanism, but there are certain cases where it provides a better user experience and the user is comfortable trusting the application/device. Thanks, George Chris Messina wrote: Hmm. Historically the separation came from the way the communities grew up actually. There were thoughts initially to make OAuth and extension of OpenID but because I was wary of the politics within the OpenID community, I pushed for keeping OAuth completely separate and avoid having to do anything with authentication (so that it could be used with OpenID, but would have its own adoption curve). The typo on the homepage was probably my fault, since, being the identity n00b, I didn't realize the difference until after I went home from the DevHouse where I put up the homepage after a couple beers. It didn't change because (apparently!) no one else seemed to read it that closely. Funny how these things develop -- not always out of explicit intention, but just because of the time allotted to get the thing out the door! ...as for your idea, George, I think I get it, and it sounds interesting. Can you give a concrete example where that could be used today? Chris On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist h...@granqvist.com mailto:h...@granqvist.com wrote: Yep. The entire authentication/authorization discussion is sadly muddled. The OAuth/OpenID hybrid proposal is adding to the confusion. Sometimes I feel like we (people who have interest in the two concepts) maintain there is a difference to justify standards' existence, even if it's largely an academic difference with no pragmatic real meaning. Other times it feels okay that they should be separate. Just one of those things, I guess. For the longest time oauth.net http://oauth.net claimed OAuth was for API authentication and no one really noticed. The only thing worth being very strict about, IMO, is identity and authentication. Never the twain should meet. It's HMACs all the way down anyway :) Hans On Wed, Jan 28, 2009 at 12:02 PM, John Kristian jmkrist...@gmail.com mailto:jmkrist...@gmail.com wrote: Yes, a digital signature can be used for authentication. SSL/TLS is one example. OAuth specifies some signing algorithms that could be used for the purpose. But it seems dangerous to extend OAuth to do authentication as well as authorization. Better for OAuth to focus on doing one thing really well. -- Chris Messina Citizen-Participant Open Web Advocate-at-Large factoryjoe.com http://factoryjoe.com # diso-project.org http://diso-project.org citizenagency.com http://citizenagency.com # vidoop.com http://vidoop.com This email is: [ ] bloggable[X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Authentication API protected with OAuth
Ah ha. I get it. That makes sense -- though it does seem like the goal should be to move away from asking for usernames and passwords. This, however, speaks to my concept of an account pin, where you could authorize desktop apps with an easy-to-remember pin that doesn't give you full account access, but only allows you to validate that you own the account. So you would have a full access password (seldom used) and an identification PIN -- almost like a security question (we know how well those work). So instead of a user inputting their username and password, they would input their username and PIN, and the PIN would be used to sign the request, proving to the SP that it's the right user -- and then the SP would provide the access token. Is that a similar but equally effective approach? Chris On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher gffle...@aol.com wrote: Thanks for this history Chris. I remember it still being API authentication in the first drafts of the OAuth IPR document; because it was one of my comments on the doc:) Here is an example usage. Again, this is more about leveraging the OAuth signature mechanism than trying to represent the whole OAuth flow. Currently at AOL we have a clientLogin API that allows a client (think destop app or mobile device) to authenticate a user and then access services at AOL. Basically, the authentication credentials are exchanged for a token that is used subsequently to access the APIs. The user's credentials are only passed to the AOL authentication service, over SSL, for validation. With the method suggested, the same validation could take place but the password would not be present in the request. Instead it would be used to sign the request. The request is only valid if the receiving authentication system can generate the signature using the password for that user. The successful response of such a request would be the API access token currently used. Another possibility (the example from the initial discussion) is using this mechanism with TLS in order to return to the client a SAML Holder-of-Key Assertion. This is the same concept of exchanging one set of credentials for another credential (in this case a SAML Assertion). I realize that there are security issues with allowing a client or API based authentication mechanism, but there are certain cases where it provides a better user experience and the user is comfortable trusting the application/device. Thanks, George Chris Messina wrote: Hmm. Historically the separation came from the way the communities grew up actually. There were thoughts initially to make OAuth and extension of OpenID but because I was wary of the politics within the OpenID community, I pushed for keeping OAuth completely separate and avoid having to do anything with authentication (so that it could be used with OpenID, but would have its own adoption curve). The typo on the homepage was probably my fault, since, being the identity n00b, I didn't realize the difference until after I went home from the DevHouse where I put up the homepage after a couple beers. It didn't change because (apparently!) no one else seemed to read it that closely. Funny how these things develop -- not always out of explicit intention, but just because of the time allotted to get the thing out the door! ...as for your idea, George, I think I get it, and it sounds interesting. Can you give a concrete example where that could be used today? Chris On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist h...@granqvist.com mailto:h...@granqvist.com wrote: Yep. The entire authentication/authorization discussion is sadly muddled. The OAuth/OpenID hybrid proposal is adding to the confusion. Sometimes I feel like we (people who have interest in the two concepts) maintain there is a difference to justify standards' existence, even if it's largely an academic difference with no pragmatic real meaning. Other times it feels okay that they should be separate. Just one of those things, I guess. For the longest time oauth.net http://oauth.net claimed OAuth was for API authentication and no one really noticed. The only thing worth being very strict about, IMO, is identity and authentication. Never the twain should meet. It's HMACs all the way down anyway :) Hans On Wed, Jan 28, 2009 at 12:02 PM, John Kristian jmkrist...@gmail.com mailto:jmkrist...@gmail.com wrote: Yes, a digital signature can be used for authentication. SSL/TLS is one example. OAuth specifies some signing algorithms that could be used for the purpose. But it seems dangerous to extend OAuth to do authentication as well as authorization. Better for OAuth to focus on doing one thing really well.
