An Introduction to the OAuth 2.0 Authorization Framework

OAuth 2.0 session presented at the PHP Lisbon community meetup

Transcript

1. An Introduction to the OAuth 2.0 authorization framework phplx meetup, February 2014 Pedro Félix @pmhsfelix pmhsfelix@gmail.com
2. 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)
3. 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
4. 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
5. 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, }
6. 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}
7. 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
8. Authentication and consent Client App Resource Server User- Agent Authorization Server Token Endpoint Authorization Endpoint Out-of-protocol interaction User Authentication and Consent
9. 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
10. Implicit grant Client App Resource Server User- Agent Authorization Server Token Endpoint Authorization Endpoint state access_token state
11. 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
12. 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
13. Grants and access tokens Client App Resource Server User- Agent access_token User Identity User Authorization Consent (Scopes) Grant
14. 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
15. 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 )
16. 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
17. 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
18. 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
19. 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": "pmhsfelix@gmail.com" }
20. 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
21. 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
22. OpenID Connect Client App UserInfo User- Agent Authorization Server Token Endpoint Authorization Endpoint state code state access_token ID token ID token ID token
23. 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
24. Q&A