2007 • 2008 -‐ IETF normaliza0on started in 2008 • 2010 -‐ RFC 5849 defines OAuth 1.0 • 2010 -‐ WRAP (Web Resource Authoriza0on Profiles) proposed by MicrosoL, Yahoo! And Google • 2010 -‐ OAuth 2.0 work begins in IETF • Working deployments of various draLs & versions at Google, MicrosoL, Facebook, Github, TwiCer, Flickr, Dropbox… • Mid 2012 – Lead author and editor resigned & withdraws his name from all specs • October 2012 – RFC 6749, RFC 6750
Authoriza0on Server Client issues access token Confiden9al/Public Trusted/Untrusted OAuth2: The Players "owns" a resource uses trusts is registered with accesses
Flow – front + back channel – "confiden9al" clients • Implicit Flow – front channel – na9ve / user agent based clients • Resource Owner Password Creden0al Flow – back channel – trusted clients • Client Creden0als Flow – back channel – service to service communica9on
Web Applica9on (Client) Resource Owner POST /token Authorization: Basic (client_id:secret) grant_type=refresh_token& refresh_token=xyz Authoriza9on Server
Designed for "confiden0al" clients – client can store secret securely – typically server-‐based applica9ons • 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 authen0ca0on – no refresh tokens – oeen combined with cookies and web views or OS APIs
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 creden0als are exposed to client – users should not become accustomed to that • S0ll beCer 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
is for (delegated) authoriza0on – authen9ca9on is part of that – …but with the authoriza9on server, not the client • OAuth2 can be used as founda0on for authen0ca0on – many "homegrown" solu9on hCp://www.thread-‐safe.com/2012/01/problem-‐with-‐oauth-‐for-‐authen0ca0on.html hCp://www.cloudiden0ty.com/blog/2013/01/02/oauth-‐2-‐0-‐and-‐sign-‐in-‐4/
contains claims about the authen0ca0on event – Issuer (iss) – Subject (sub) – Audience (aud) – Expira9on (exp) • Client must validate the ID token at this point
founda0on (or framework) – least common denominator technology – delegated authoriza9on – extensible • OpenID Connect is an authen0ca0on protocol – built on top of OAuth2 extensibility – interoperable • JSON Web Token is a standardized token format – issuer, life9me, audience + other claims – signatures & encryp9on