An Introduction to the OAuth 2.0 authorization framework phplx meetup, February 2014 Pedro Félix @pmhsfelix [email protected] 

whoami • Professor at ISEL (Lisbon Polytechnic Institute) • Software engineer • Currently working with SAPO - Service Delivery Broker team • Co-author of Designing Evolvable Web APIs with ASP.NET (to be published in 2014 by O’Reilly) 

OAuth History • OAuth started circa 2007 • Constrained authorization delegation • 2010 - RFC 5849 defines OAuth 1.0 • 2010 - OAuth 2.0 work begins at IETF • 2012 • RFC 6749 - The OAuth 2.0 Authorization Framework • RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage • Work still going on • e.g. dynamic client registration 

Token usage Client App Resource Server User- Agent access_token GET /resource HTTP/1.1 Authorization: Bearer the.access.token POST /resource HTTP/1.1 Content-Type: application/x-www-form-urlencoded access_token=the.access.token GET /resource?access_token=the.access.token HTTP/1.1 

Token request – client credentials grant Client App Resource Server User- Agent Authorization Server Token Endpoint access_token client_secret client_id POST /token_endpoint HTTP/1.1 Content-Type: application/x-www-form-urlencoded Authorization: Basic {client_id:client_secret} grant_type=client_credentials& scope={requested-access-scope}& client_id=…&client_secret=… HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "access_token":"the.access.token", "token_type":"Bearer", "expires_in":3600, } 

Resource owner password grant Client App Resource Server User- Agent Authorization Server Token Endpoint access_token client_secret client_id password username password username POST /token_endpoint HTTP/1.1 Content-Type: application/x-www-form-urlencoded Authorization: Basic {client_id:client_secret} grant_type=password& username=alice& password=the.password& scope={requested-access-scope} 

Authorization code grant Client App Resource Server User- Agent Authorization Server Token Endpoint Authorization Endpoint client_id redirect_uri scope state GET /authorization_endpoint?response_type=code &client_id=... &state=... &redirect_uri=... &scope=... HTTP/1.1 

Authentication and consent Client App Resource Server User- Agent Authorization Server Token Endpoint Authorization Endpoint Out-of-protocol interaction User Authentication and Consent 

Authorization code grant Client App Resource Server User- Agent Authorization Server Token Endpoint Authorization Endpoint state code state HTTP/1.1 302 Found Location: https://the.redirect.uri? code=... &state=xyz access_token client_secret client_id code 

Implicit grant Client App Resource Server User- Agent Authorization Server Token Endpoint Authorization Endpoint state access_token state 

Authorization grant • Authorization Code Grant • User authentication and consent provided at direct at Authorization Server • Implicit Grant • Similar to previous, no client authentication • Resource Owner Password Credentials Grant • User gives password to Client, Client uses it to obtain access token • Client Credentials Grant • No user, Client accesses on its own behalf 

The grant concept • Access token issuance based on a grant • Grant represents the logical outcome of • Client authentication • User authentication and consent • Not a protocol concept • Core domain concept • Bound to all the Authorization Server artifacts • Code • Access token • Refresh token 

Grants and access tokens Client App Resource Server User- Agent access_token User Identity User Authorization Consent (Scopes) Grant 

Front channel vs back channel • Front channel • Authorization Endpoint • Authorization request – redirect from Client to AE via the User-agent • Authorization response – redirect from AE to Client via the User-agent • Human interface and out-of-protocol interactions • User authentication and authorization consent • Not secure for Client secrets – no Client authentication • Back channel • Token Endpoint • Direct request-response between Client and Token Endpoint • No User interaction • Optional Client authentication 

Client Types • Confidential “Clients capable of maintaining the confidentiality of their credentials” (e.g. client implemented as a secure Web server) • Public “Clients incapable of maintaining the confidentiality of their credentials” (e.g. clients executing on the device used by the resource owner, i.e., native apps or client-side Web apps ) 

Security problems • Clear-text credentials • Bearer token • Client secret • Username and password • Authorization code • Complete reliance on transport security • Session fixation via CSRF • Use the state parameter to correlate requests to responses • Front-channel code and token stealing • Enforce strict redirect URIs 

Bearer vs. MAC • Bearer • Simpler – no signatures • Require HTTPS • Beware of incorrect use • RFC 6750 • Similar to cookie usage • Behare of the fallacy • Same origin policies • Discoverability • MAC • Safer • More complex – signature • Client library integration 17 

Access token format and processing • OAuth 2.0 • Does not define access token format • Does not define token processing rules • Tight coupling between Authorization Server and Resource Server • Typically run by the same organization • Using opaque formats and processing rules • No protocol provision for cross-boundary AS and RS interaction 18 

JSON Web Token eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzZWxmIiwiYXVkIjoiaHR0cDo vL3BocGx4Lm5ldC8iLCJuYmYiOjEzOTE2MjU2NjYsImV4cCI6MTM5MTYyNzQ2Niwi bmFtZSI6IlBlZHJvIiwic3ViIjoicG1oc2ZlbGl4QGdtYWlsLmNvbSIsInJvbGUiOiJBdXRo b3IifQ._2fIIqUY40e1ewciRklN-nxBqKUNNcsZcrgx8FCrZnw { "alg": "HS256", "typ": "JWT" } { "name": "Pedro", "iss": "self", "nbf": 1391625666, "role": "Author", "exp": 1391627466, "aud": "http://phplx.net/", "sub": "[email protected]" } 

OAuth 2.0 and authentication • OAuth 2.0 is an authorization framework • But everybody is using it also for authentication • E.g. social logins with Google, Facebook and Github • Using OAuth 2.0 for Authentication • RS exposes a resource with the User’s identity • Is that OK? • It depends! • Not secure in the general case – token reusage • Not interoperable 

OpenID Connect • “OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol” • Adds features to OAuth 2.0 • Very different from OpenID 2.0 • Defines • UserInfo resource for obtaining the User claims • ID token - standard token format to transmit claims • Standard claims and scopes for authentication • Unified solution for authentication and authorization • Being adopted by Google, Microsoft and others 

OpenID Connect Client App UserInfo User- Agent Authorization Server Token Endpoint Authorization Endpoint state code state access_token ID token ID token ID token 

References • IETF Web Authorization Working Group - http://datatracker.ietf.org/wg/oauth/ • RFCs • Drafts • OpenID Connect - http://openid.net/connect/ • https://github.com/pmhsfelix/OAuth2.Demos.AuthzCodeGrant • https://github.com/webapibook/WebApiBook.Security • Eran Hammer • OAuth 2.0 and the Road to Hell - http://hueniverse.com/2012/07/oauth-2-0-and- the-road-to-hell/ • OAuth 2.0 - Looking Back and Moving On - http://vimeo.com/52882780 • John Bradley - http://www.thread-safe.com/2012/07/the-oauth-2-sky-is-not- falling.html 

Q&A