An introduction to OAuth and OpenID Connect
910 likes | 2.19k Vues
An introduction to OAuth and OpenID Connect. Background. Introduction. Why OAuth ? History of OAuth Overview of OAuth 2.0 What is OpenID Connect Issues with OAuth 2.0. Why OAuth ?. Classic Scenario. Trusted subsystems Classic security is intranet only
An introduction to OAuth and OpenID Connect
E N D
Presentation Transcript
Introduction • Why OAuth? • History of OAuth • Overview of OAuth 2.0 • What is OpenIDConnect • Issues with OAuth 2.0
Classic Scenario • Trusted subsystems • Classic security is intranet only • Active Directory/LDAP/Kerberos
Enterprise to Enterprise • Trusted external parties • Soap, Xml, WS-*
Mobile Computing • No enterprise security integration • Lightweight • Low power • HTTP/JSON/HTML5
In the Beginning • Online services • 3rd party applications • Insecure
OAuth 1.0 • An open standard • Based on current best practice • Released Nov 2007 • Still had issues
OAuth 1.0 Issues • Complex • Limited scope • Didn’t scale
OAuth 2.0 Client Profiles • Server side web application • Client side (browser) application • Native application
OAuth 2.0 Roles Resource Owner Client Application Resource Server Authorization Server
Access Token • Bearer Tokens • Not Crypto signed • SSL/TLS required • Transmission • Header (Preferred) • Querystringparam • Form encoded param
OAuth 2.0 Authorization Flows • Authorization Code • Implicit Grant • Resource Owner Password • Client Credentials • Device Profile • SAML Bearer Assertion Profile
Authorization Code Flow • Server to Server • Best used: • OAuth client is a web server • Long-lived access • Access Accountability
Authorization Code Flow • GET accounts.google.com/o/ oauth2/auth • client_id=mossbook& • scope= googleapis.com/auth/ tasks • redirect_uri=https://mossbook.com/cb& • response_type=code& • state=999
Authentication Authorisation
Retrieve Access token GET mossbook.com/cb? code=762475&state=999 POST /token authorization: Basic (client_id:secret) grant_type=authorization_code& redirect_uri=https://mossbook.com/cb • { • “access_token” : “abc”, • “exipres_in” : “3600”, • “token_type” : “Bearer” • “refresh_token” : “xyz” • }
Access Resources GET googleapis.com/tasks/1/lists/tasks/all
Implicit Grant • GET accounts.google.com/o/ oauth2/auth • client_id=mossbook& • scope= googleapis.com/auth/ tasks • redirect_uri=https://mossbook.com/cb& • response_type=token& • state=999
Resource Owner Password • For trusted clients/devices • Credentials collected • User experience traditional form
Client Credentials • Machine to Machine • Client owns the data • Not widely Implemented
Insecure Impersonation
OpenID • Built on top of OAuth 2.0 • Standardises: • UserInfo resource • An extra token type • Added protocol validation • Coming soon: • Session Management • Discovery • Dynamic registration
OpenID Connect Flow • GET accounts.google.com/authorise • client_id=mossbook& • scope= openid • redirect_uri=https://mossbook.com/cb& • response_type=code& • state=999 • { • “access_token” : “abc”, • “id_token” : “rst”, • “exipres_in” : “3600”, • “token_type” : “Bearer” • “refresh_token” : “xyz” • }
Its Hammer time! “When compared to OAuth 1.0 the 2.0 specification is more complex, less interoperable, less useful, more incomplete, and most importantly, less secure” Eran Hammer
Design by Committee • Evolved into a framework • Not explicit enough • Multiple interpretations • Open Standard • Insecure
Defence in Depth? • Bearer tokens not tied to request • Reliance on SSL • Developers WTF?? • Infrastructure level bypass • Pineapples
Controvsey Another Eran Hammer “OAuth is dead” picture from RealTimeConf 2012
Authorisation • OAuth 2.0 • Authentication • OpenID Connect Thank-you very much, you’ve been a great audience
References • http://oauth.net/ • http://hueniverse.com/ • http://www.leastprivilege.com