910 likes | 2.16k Views
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
E N D
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