2007 • 2008 -‐ IETF normalizaTon started in 2008 • 2010 -‐ RFC 5849 defines OAuth 1.0 • 2010 -‐ WRAP (Web Resource AuthorizaTon Profiles) proposed by MicrosoG, Yahoo! And Google • 2010 -‐ OAuth 2.0 work begins in IETF • Working deployments of various draGs & versions at Google, MicrosoG, Facebook, Github, Twi.er, Flickr, Dropbox… • Mid 2012 – Lead author and editor resigned & withdraws his name from all specs • October 2012 – RFC 6749, RFC 6750
AuthorizaTon Server Client issues access token Confiden9al/Public Trusted/Untrusted OAuth2: The Players "owns" a resource uses trusts is registered with accesses
Web Applica9on (Client) Resource Owner POST /token Authorization: Basic (client_id:secret) grant_type=refresh_token& refresh_token=xyz Authoriza9on Server
Designed for server-‐based applicaTons – Client can store secret securely on the server • Accountability is provided – access token never leaked to the browser • Long-‐lived access can be implemented
Server Resource Owner Client GET /authorize? client_id=nativeapp& scope=resource& redirect_uri=http://localhost/cb& response_type=token& state=123 Authoriza9on Server
Simplified handshake – no authoriza9on code • Token is exposed to browser / local OS • No client authenTcaTon – no refresh tokens – some9mes cookies and web views used instead • Heavily debated and many "non-‐standard" variaTons
Owner Client Authoriza9on Server POST /token Authorization: Basic (client_id:secret) grant_type=password& scope=resource& user_name=owner& password=password& Resource Server
Creden9al Flow • Resource owner credenTals are exposed to client – users should not become accustomed to that • STll be.er to store access/refresh token on device than password – if the developer is using that feature • Typically client and back end built by same party
• h.p://hueniverse.com/2010/09/oauth-‐2-‐0-‐without-‐signatures-‐is-‐bad-‐ for-‐the-‐web/ • h.p://hueniverse.com/2012/07/oauth-‐2-‐0-‐and-‐the-‐road-‐to-‐hell/ • OAuth2: Looking back and moving on – h_ps://vimeo.com/52882780
the property that any party !in possession of the token (a "bearer") can use the !token in any way that any other party in possession !of it can. Using a bearer token does not !require a bearer to prove possession of !cryptographic key material (proof-of-possession).!
is for (delegated) authorizaTon – authen9ca9on is a pre-‐requisite for that • What most developers really want is: – let's use OAuth2 for authen9ca9on • "Sign-‐in with social provider X" • à especially mobile apps h.p://www.thread-‐safe.com/2012/01/problem-‐with-‐oauth-‐for-‐authenTcaTon.html h.p://www.cloudidenTty.com/blog/2013/01/02/oauth-‐2-‐0-‐and-‐sign-‐in-‐4/
is useful for many typical applicaTons scenarios • Spec needs some refinement – "basic profile" – MAC tokens • Current implementaTons are lacking – even by the big guys – let alone the myriad of DIY implementa9ons • Very good & balanced view – h_ps://www.tbray.org/ongoing/When/201x/2013/01/23/OAuth