The State of OAuth2
Upcoming SlideShare
Loading in...5
×
 

The State of OAuth2

on

  • 3,230 views

Slides from my talk at State of the Auth in Portland

Slides from my talk at State of the Auth in Portland

Statistics

Views

Total Views
3,230
Views on SlideShare
3,115
Embed Views
115

Actions

Likes
4
Downloads
64
Comments
0

3 Embeds 115

http://aaronparecki.com 112
https://twitter.com 2
http://pk.dev 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The State of OAuth2 The State of OAuth2 Presentation Transcript

  • The State ofOAuth 2Aaron Parecki • @aaronpk • aaronparecki.comState of the Auth • January 2013
  • Before OAuth Apps stored the user’s password Apps got complete access to a user’s account Users couldn’t revoke access to an app except by changing their password Compromised apps exposed the user’s passwordaaron.pk/oauth2 @aaronpk
  • Before OAuth Services recognized the problems with password authentication Many services implemented things similar to OAuth 1.0 Each implementation was slightly different, certainly not compatible with each otheraaron.pk/oauth2 @aaronpk
  • Before OAuth 1.0 Flickr: “FlickrAuth” frobs and tokens Google: “AuthSub” Facebook: requests signed with MD5 hashes Yahoo: BBAuth (“Browser-Based Auth”)aaron.pk/oauth2 @aaronpk
  • Some Current Implementers
  • The OAuth 2 Spec http://oauth.net/2/
  • Definitions Resource Owner: The User Resource Server: The API Authorization Server: Often the same as the API server Client: The Third-Party Applicationaaron.pk/oauth2 @aaronpk
  • Use Cases Web-server apps Browser-based apps Username/password access Application access Mobile appsaaron.pk/oauth2 @aaronpk
  • Use Cases – Grant Types Web-server apps – authorization_code Browser-based apps – implicit Username/password access – password Application access – client_credentials Mobile apps – implicitaaron.pk/oauth2 @aaronpk
  • Web Server Apps Authorization Code Grantaaron.pk/oauth2 @aaronpk
  • Create a “Log In” linkLink to:https://facebook.com/dialog/oauth?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=REDIRECT_URI&scope=emailaaron.pk/oauth2 @aaronpk
  • Create a “Log In” linkLink to:https://facebook.com/dialog/oauth?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=REDIRECT_URI&scope=emailaaron.pk/oauth2 @aaronpk
  • Create a “Log In” linkLink to:https://facebook.com/dialog/oauth?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=REDIRECT_URI&scope=emailaaron.pk/oauth2 @aaronpk
  • Create a “Log In” linkLink to:https://facebook.com/dialog/oauth?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=REDIRECT_URI&scope=emailaaron.pk/oauth2 @aaronpk
  • Create a “Log In” linkLink to:https://facebook.com/dialog/oauth?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=REDIRECT_URI&scope=emailaaron.pk/oauth2 @aaronpk
  • User visits the authorization pagehttps://facebook.com/dialog/oauth?response_type=code&client_id=28653682475872&redirect_uri=everydaycity.com&scope=emailaaron.pk/oauth2 @aaronpk
  • On success, user is redirected backto your site with auth codehttps://example.com/auth?code=AUTH_CODE_HEREOn error, user is redirected back toyour site with error codehttps://example.com/auth?error=access_deniedaaron.pk/oauth2 @aaronpk
  • Server exchanges auth codefor an access tokenYour server makes the following requestPOSThttps://graph.facebook.com/oauth/access_tokenPost Body:grant_type=authorization_code&code=CODE_FROM_QUERY_STRING&redirect_uri=REDIRECT_URI&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRETaaron.pk/oauth2 @aaronpk
  • Server exchanges auth codefor an access tokenYour server gets a response like the following{ "access_token":"RsT5OjbzRn430zqMLgV3Ia", "token_type":"bearer", "expires_in":3600, "refresh_token":"e1qoXg7Ik2RRua48lXIV"}or if there was an error{ "error":"invalid_request"}aaron.pk/oauth2 @aaronpk
  • Browser-Based Apps Implicit Grantaaron.pk/oauth2 @aaronpk
  • Create a “Log In” linkLink to:https://facebook.com/dialog/oauth?response_type=token&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=emailaaron.pk/oauth2 @aaronpk
  • User visits the authorization pagehttps://facebook.com/dialog/oauth?response_type=token&client_id=2865368247587&redirect_uri=everydaycity.com&scope=emailaaron.pk/oauth2 @aaronpk
  • On success, user is redirected backto your site with the access token inthe fragmenthttps://example.com/auth#token=ACCESS_TOKENOn error, user is redirected back toyour site with error codehttps://example.com/auth#error=access_deniedaaron.pk/oauth2 @aaronpk
  • Browser-Based AppsUse the “Implicit” grant typeNo server-side code neededClient secret not usedBrowser makes API requests directlyaaron.pk/oauth2 @aaronpk
  • Username/Password Password Grantaaron.pk/oauth2 @aaronpk
  • Password GrantPassword grant is only appropriate for trustedclients, most likely first-party apps only.If you build your own website as a client of yourAPI, then this is a great way to handle loggingin.aaron.pk/oauth2 @aaronpk
  • Password Grant Type Only appropriate for your service’s website or your service’s mobile apps.aaron.pk/oauth2
  • Password GrantPOST https://api.example.com/oauth/tokenPost Body:grant_type=password&username=USERNAME&password=PASSWORD&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRETResponse:{ "access_token":"RsT5OjbzRn430zqMLgV3Ia", "token_type":"bearer", "expires_in":3600, "refresh_token":"e1qoXg7Ik2RRua48lXIV"}aaron.pk/oauth2 @aaronpk
  • Password GrantUser exchanges username and password for a tokenNo server-side code neededClient secret only used from confidential clients (Don’t send client secret from a mobile app!)Useful for developing a first-party login systemaaron.pk/oauth2 @aaronpk
  • Application Access Client Credentials Grantaaron.pk/oauth2 @aaronpk
  • Client Credentials GrantPOST https://api.example.com/1/oauth/tokenPost Body:grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRETResponse:{ "access_token":"RsT5OjbzRn430zqMLgV3Ia", "token_type":"bearer", "expires_in":3600, "refresh_token":"e1qoXg7Ik2RRua48lXIV"}aaron.pk/oauth2 @aaronpk
  • Grant Type Summary authorization_code: Web-server apps implicit: Mobile and browser-based apps password: Username/password access client_credentials: Application accessaaron.pk/oauth2 @aaronpk
  • Grant Types & Response Types authorization_code: response_type=code implicit: response_type=tokenaaron.pk/oauth2 @aaronpk
  • Grant Type Reviewaaron.pk/oauth2 @aaronpk
  • Authorization Code User visits auth page response_type=code User is redirected to your site with auth code http://example.com/?code=xxxxxxx Your server exchanges auth code for access token POST /token code=xxxxxxx&grant_type=authorization_codeaaron.pk/oauth2 @aaronpk
  • Implicit User visits auth page response_type=token User is redirected to your site with access token http://example.com/#token=xxxxxxx Token is only available to the browser since it’s in the fragmentaaron.pk/oauth2 @aaronpk
  • Password Your server exchanges username/password for access token POST /token username=xxxxxxx&password=yyyyyyy& grant_type=passwordaaron.pk/oauth2 @aaronpk
  • Client Credentials Your server exchanges client ID/secret for access token POST /token client_id=xxxxxxx&client_secret=yyyyyyy& grant_type=client_credentialsaaron.pk/oauth2 @aaronpk
  • Mobile Apps Implicit Grantaaron.pk/oauth2 @aaronpk
  • aaron.pk/oauth2 @aaronpk
  • aaron.pk/oauth2 @aaronpk
  • Redirect back to your app Facebook app redirects back to your app using a custom URI scheme. Access token is included in the redirect, just like browser-based apps. fb2865://authorize/#access_token=BAAEEmo2nocQBAFFOeRTdaaron.pk/oauth2 @aaronpk
  • aaron.pk/oauth2 @aaronpk
  • Mobile ApplicationsUse the “Implicit” grant typeNo server-side code neededClient secret not usedMobile app makes API requests directlyaaron.pk/oauth2 @aaronpk
  • Mobile Applications External user agents are best Use the service’s primary app for authentication, like Facebook – provides a superior user experience Or open native Safari on iPhone, still better than using an embedded browser Auth code or implicit grant type In both cases, the client secret should never be used, since it is possible to decompile the app which would reveal the secretaaron.pk/oauth2 @aaronpk
  • Accessing Resources So you have an access token. Now what?aaron.pk/oauth2 @aaronpk
  • Use the access token to makerequestsNow you can make requests using the access token.GET https://api.example.com/meAuthorization: Bearer RsT5OjbzRn430zqMLgV3IaAccess token can be in an HTTP header or a query stringparameterhttps://api.example.com/me?access_token=RsT5OjbzRn430zqMLgV3Iaaaron.pk/oauth2 @aaronpk
  • Eventually the access tokenmay expireWhen you make a request with an expired token, you willget this response{ "error":"expired_token"}Now you need to get a new access token!aaron.pk/oauth2 @aaronpk
  • Get a new access token usinga refresh tokenYour server makes the following requestPOST https://api.example.com/oauth/tokengrant_type=refresh_token&reresh_token=e1qoXg7Ik2RRua48lXIV&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRETYour server gets a similar response as the original call tooauth/token with new tokens.{ "access_token":"RsT5OjbzRn430zqMLgV3Ia", "expires_in":3600, "refresh_token":"e1qoXg7Ik2RRua48lXIV"}aaron.pk/oauth2 @aaronpk
  • Scope Limiting access to resoucesaaron.pk/oauth2 @aaronpk
  • Limiting Access to Third Partiesaaron.pk/oauth2 @aaronpk
  • Limiting Access to Third Partiesaaron.pk/oauth2 @aaronpk
  • Limiting Access to Third Partiesaaron.pk/oauth2 @aaronpk
  • OAuth 2 scope Created to limit access to the third party. The scope of the access request expressed as a list of space-delimited strings. In practice, many people use comma-separators instead. The spec does not define any values, it’s left up to the implementor. If the value contains multiple strings, their order does not matter, and each string adds an additional access range to the requested scope.aaron.pk/oauth2 @aaronpk
  • OAuth 2 scope on Facebook https://www.facebook.com/dialog/oauth? client_id=YOUR_APP_ID&redirect_uri=YOUR_URL &scope=email,read_streamaaron.pk/oauth2 @aaronpk
  • OAuth 2 scope on Facebookaaron.pk/oauth2 @aaronpk
  • OAuth 2 scope on Github https://github.com/login/oauth/authorize? client_id=...&scope=user,public_repo user • Read/write access to profile info only. public_repo • Read/write access to public repos and organizations. repo • Read/write access to public and private repos and organizations. delete_repo • Delete access to adminable repositories. gist • write access to gists.aaron.pk/oauth2 @aaronpk
  • OAuth 2 scope The challenge is displaying this to the user succinctly in a way they will actually understand If you over-complicate it for users, they will just click “ok” until the app works, and ignore any warnings Read vs write is a good start for basic servicesaaron.pk/oauth2 @aaronpk
  • So what’s wrong?aaron.pk/oauth2 @aaronpk
  • What I just described is one possible implementation of an OAuth 2 serveraaron.pk/oauth2 @aaronpk
  • Indecision No required token type No agreement on the goals of an HMAC-enabled token type No requirement to implement token expiration No guidance on token string size, or any value for that matter No strict requirement for registration Loose client type definitionaaron.pk/oauth2 @aaronpk
  • Indecision (continued) Lack of clear client security properties No required grant types No guidance on the suitability or applicability of grant types No useful support for native applications (but lots of lip service) No required client authentication method No limits on extensionsaaron.pk/oauth2 Source: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ @aaronpk
  • The result: the OAuth RFC is a framework, not a protocolaaron.pk/oauth2 @aaronpk
  • aaron.pk/oauth2 @aaronpk
  • aaron.pk/oauth2 @aaronpk
  • OAuth 2 Servers Implementing an OAuth 2 Serveraaron.pk/oauth2 @aaronpk
  • Implementing an OAuth 2 Server
  • Implementing an OAuth 2 Server Find a server library already written: A short list available here: http://oauth.net/2/ Read the OAuth spec in its entirety Study other implementations like Google Make decisions based on the security requirements of your application. In many cases the spec says SHOULD and leaves the choice up to the implementer. Understand the security implications of the implementation choices you make.aaron.pk/oauth2 @aaronpk
  • Implementing an OAuth 2 Server Choose which grant types you want to support Authorization Code – for traditional web apps Implicit – for browser-based apps and mobile apps Password – for your own website or mobile apps Client Credentials – if applications can access resources on their own Choose whether to support Bearer tokens, MAC or both If using Bearer tokens, choose whether to use a DB lookup or use self-container tokens Define appropriate scopes for your serviceaaron.pk/oauth2 @aaronpk
  • Access Tokens Bearer tokens vs MAC tokensaaron.pk/oauth2 @aaronpk
  • Bearer Tokens GET /1/profile HTTP/1.1 Host: api.example.com Authorization: Bearer B2mpLsHWhuVFw3YeLFW3f2 Bearer tokens are a cryptography-free way to access protected resources. Relies on the security present in the HTTPS connection, since the request itself is not signed. Application developers do not need to do any cryptography, they just pass the token string in the header.aaron.pk/oauth2 @aaronpk
  • Dangers of Using Bearer TokensRequests are not signed, so are vulnerable to reply attacks if someone intercepts the token.When storing tokens in cookies, must ensure the cookie is only sent via an https connection.If a token is leaked, there is a large potential for abuse.aaron.pk/oauth2 @aaronpk
  • Security Recommendationsfor Clients Using Bearer TokensSafeguard bearer tokensValidate SSL certificatesAlways use httpsDon’t store bearer tokens in plaintext cookiesIssue short-lived bearer tokensDon’t pass bearer tokens in page URLsaaron.pk/oauth2 @aaronpk
  • MAC TokensGET /1/profile HTTP/1.1Host: api.example.comAuthorization: MAC id="jd93dh9dh39D", nonce="273156:di3hvdf8”, mac="W7bdMZbv9UWOTadASIQHagZyirA="MAC tokens provide a way to make authenticated requests withcryptographic verification of the request.Similar to the original OAuth 1.0 method of using signatures.Application developers must sign each request, preventing forgeryand replay even when requests are sent in the clear. @aaronpk
  • Bearer, MAC, or Both? Should you support Bearer tokens, MAC tokens or both? MAC tokens are technically safer and more secure Application developers will prefer working with Bearer tokens since it is easieraaron.pk/oauth2 @aaronpk
  • Scalability Concerns Token lookups from a database can become a bottleneck. Can be addressed by heavy use of caching to avoid DB lookups Can be addressed by a good master/slave database architecture An alternative is to use “self-encoded” tokens where all the needed information is contained within the token string itself, avoiding the need to do a database lookupaaron.pk/oauth2 @aaronpk
  • Self-Encoded Tokens The token is a string which is encrypted or signed The string contains all necessary information to avoid doing a database lookup These tokens cannot be revoked, so must expire frequently (requires heavy use of the refresh_token grant type) Can be implemented with either Bearer or MAC tokensaaron.pk/oauth2 @aaronpk
  • DB Token Lookups vs Self-Encoded Tokens Token table probably looks like Token User ID Expiration Date Scopes Instead, encode that into a JSON payload which *is* the token:  {“user_id”:1000,”exp”:1355429676,”scopes”:[“email ”,”payment”]} See JSON Web Signature for example of signing this tokenaaron.pk/oauth2 @aaronpk
  • JSON Web Signature http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07 Data Base64 Encoded { "typ":"JWT", eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 "alg":"HS256” } { "usr":"username", eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MT "exp":1300819380, kzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9p "scope":["profile"] c19yb290Ijp0cnVlfQ } Signature dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEaaron.pk/oauth2 @aaronpk
  • JSON Web Signature Complete Token Example: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3M iOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA 6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ 4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk Header, data, signature are base64 encoded and concatenated with a “period” between each.aaron.pk/oauth2 @aaronpk
  • oauth.netaaron.pk/oauth2 @aaronpk
  • oauth.net Website http://oauth.net Source code available on Github github.com/aaronpk/oauth.net Please feel free to contribute to the website Contribute new lists of libraries, or help update informationaaron.pk/oauth2 @aaronpk
  • github.com/aaronpk/oauth.netaaron.pk/oauth2 @aaronpk
  • Thanks. Aaron Parecki @aaronpk aaronparecki.comgithub.com/aaronpk