OAuth 2.0 WTF
Issue/Topic: OAuth 2.0 & OpenID connect
Monday – 1I
Conference: IIW10 May 17-19, 2009 this is the complete Complete Set of Notes
Convener: David, Joseph, Eran, Allen
Notes-taker(s): Judith
Discussion notes:
OAuth 1 was (is) influential, but not adapted widely. Crypto implementation is hard. The discussion illustrated the tension between ease of implementation and security. If it's too hard, we know web developers will do something MUCH less secure. See http://hueniverse.com for some good blog entries
Finally, parts of the spec are being locked down in the next month or two: only changes that will be accepted will be those to enable interop or security.
Introduction
In draft form; implementations in ruby, PHP, Cocoon, Perl. Servers are twitter & facebook. (Not sure but believe this is being developed with IETF standards.)
- Now simplified. Rely on SSL, skip signing.
- Now with more flows: web, desktop device, mobile, etc. (This simplifies over the attempt to have one unified flow.)
- Now a notion of refreshing tokens, so temporary access tokens.
- Now to provide a place to list scopes. Currently providers define own scope. Questions on how to reduce scope.
Q&A
Security in webserver flow - type access code in URL.
A voiced dislike of having SSL. Signatures is an option to get away from SSL. Also short lived tokens like one use.
A voiced dislike of access code in URLs. What about server logs? Pass it using headers or POST (not sure I heard it right, with further discussion of PUT & GET).
Signatures are now more simple, only one algorithm. Gives developer an option to not use bearer tokens. Yahoo notes that the security needed for signature secret can be contained and by distributing bearer secrets limit risk exposure.
Version 1.0 Access tokens lived forever, but could be revoked. Version 2.0 Refresh token lives forever, only used to get access token which is short lived.
Extensions:
- Providing: additional flows in req type option with a registry.
- Additional parameters like display parameter. Name space registry. Use IANA?
- options with signatures.
Twitpic is a 4th party usecase: open discussion.
Next
- OpenID 2.0 connect
- Synthesis of OpenID & OAuth in the past: boat car.
- OAuth required preexisting relationships
- OpenID open relationships, didnt require preexisting
Twitter built ID on top of OAuth, other providers have been hacking different solutions.
OAuth2 has scope: Call this one OpenID to get ID and some profile info (another scope email?).
Response is an identifier (Webfinger account URI or https URL). Time issued. &ccess token (just for the OpenId scope?)
Scope call with access key gets a collection of five or six reseved keys including names and profile URLs. Potential to express endpoints for requesting various resources like portable contacts.
Separate profile url from identifier, thus widely personalized profile sources (like OpenID) but rigorous standards for the implementation.
Discovery flow & technology: LLRD....
Eve pushes back that some information may be useful on initial claim. Much discussion about modular design goals, making it simple.
Demo implementations ontop of existing OAuth 2 is only a few more lines of code.
Simple to do the core easy stuff, but allowing some hooks to solve different & difficult problems.
