oauth 2.0 misconceptions
TRANSCRIPT
Misconceptions of OAuth 2.0
Cory Forsyth
@bantic
201 Created
Consultants in New York City
Logan, UT
“A set of clean abstractions for authentication in Ember.js”
OAutha short intro
OAuth 1.0 & 2.0• A delegated authorization protocol/framework
• Canonical example:
• User wants to print photos
• Photos are stored at my-pix.com
• User grants authorization to print-me.com to access photos at my-pix.com
• Solves the “share my password” anti-pattern
OAuth• 1.0:
• Uses cryptographic signatures, server-to-server communication
• 2.0:
• Includes “implicit grant” (front-end only) flow
• Includes “authorization code grant” flow
• No signatures (encrypted https communication only)
• Both:
• browser-centric redirection-based flows
OAuth• 1.0:
• A protocol
• 2.0:
• “Simpler”
• Less secure?
• A framework
OAuth Love TriangleResource Owner
(user)
Resource / Authorization
Server (my-pix.com)
Client (print-me.com)
visits1 directs browser to2
consent screen3
redirects to, with authz in url
4
OAuth Love Triangle
User e.g. Google+
your ember app
visits1 opens popup to2
consent screen3
redirects to, with authz in url
4
OAuth 1 & 2 Terminology• Resource Owner / User
• Human, likes taking and printing pictures
• Client / Consumer
• E.g., print-me.com
• For most people in this room: You code OAuth clients
• Server / Service Provider
• E.g., my-pix.com (and Google+, Facebook, Github, etc.)
OAuth Clients• Can be confidential or public
• Public clients include:
• JavaScript that runs in the browser
• Native Apps (could be decompiled)
• Must be registered with a provider — provider issues client_id, client_secret
OAuth 2 Flows
• Authorization Code Grant
• Implicit Grant
• 2 others, less important
OAuth 2 Flows• Client crafts URL pointing at provider, redirects
browser to it
• e.g. https://accounts.google.com/o/oauth2/auth? client_id=xyz& redirect_uri=my-pix.com/callback& response_type=code or token& scope=email& …=…
OAuth 2 Flows
• Server / Provider authenticates user
• Obtains authorization consent
• Redirects back to redirect_uri with code, e.g. http://my-pix.com/callback? code=abc123
Authorization Code Grant• Client redirects to provider endpoint with client_id,
redirect_uri, token_type=code, scope, etc, query params
• Provider authenticates user, obtains authorization consent, redirects to redirect_uri with code=abc123 query param
• Client POSTs to provider with client_id, grant_type=authorization_code, code=abc123, redirect_uri
• Provider responds to client with access_token
Implicit Grant• Client redirects to provider endpoint with client_id,
redirect_uri, token_type=token, scope, etc, query params
• Provider authenticates user, obtains authorization consent, redirects to redirect_uri with access_token=abc123 hash fragment
• e.g. print-me.com/callback#access_token=abc123
Misunderstanding #1 Access vs Bearer Tokens
• Clients use access tokens to make requests of providers for protected resources (on behalf of users)
• Clients present “bearer” access tokens as query parameters, headers (“Authorization: Bearer xyz”), or form parameters
Access vs Bearer Tokens
Access vs Bearer Tokens
• Access Tokens are almost always Bearer Tokens
• Providers include “token_type” when issuing tokens
• “bearer” is a token_type (there is also “mac”)
• Called “Bearer” because the Provider will allow any request with the token present (whoever holds/“bears” the token has access)
Misunderstanding #2 All Bearer Tokens are Created Equal
Client X gets token via authorization code grant
Client X gets token via implicit grant
Client Y gets token via authorization code grant
Client Y gets token via implicit grant
Same user, provider, scope, token is not expired. Spot the difference:
Misunderstanding #2 All Bearer Tokens are Created Equal
• Access tokens are opaque to client
• Client cannot tell:
• What client the token was issued for
• When the token expires
• If the token is valid
Misunderstanding #3 Refresh Tokens “refresh” nothing• What is a refresh token?
• Optionally issued by OAuth provider in certain scenarios:
• when requested with “scope”
• in Authorization Code Grant (server-side) flow
• Becaus: Clients cannot know when access token is invalid
Misunderstanding #3 Refresh Tokens “refresh” nothing
• “You cannot refresh an implicit grant token”
• “You can only refresh an access token from Authorization Code grant”
Misunderstanding #3 Refresh Tokens “refresh” nothing
• “You cannot refresh an implicit grant token”
• “You can only refresh an access token from Authorization Code grant”
Misunderstanding #3 Refresh Tokens “refresh” nothing
Misunderstanding #4 OAuth does not do authentication
• authentication: Who are you?
• authorization: What are you allowed to do?
• OAuth 2.0: An Authorization Framework
Misunderstanding #4 OAuth does not do authentication
Naive OAuth Authentication:
• Get access token via implicit grant (request ‘email’ scope)
• Use access token to read email from OAuth provider (i.e. `GET /me?access_token=XYZ`)
• Use the email to find user in your database, log them in
•After all, if the access token provides that email, that’s who they are, right?
Misunderstanding #4 OAuth does not do authentication
• Remember, access token is opaque to client
• Client cannot tell:
• who that token was issued for
• when that token was issued
• Simple to intercept redirect, inject another access token
Misunderstanding #4 OAuth does not do authentication• What does work?
• authorization code flow (server-side) with ‘state’ param:
• ensures access token is “fresh”, for this client
• OpenID Connect
• Builds upon OAuth, uses JWT
• Allow in-browser verification of token integrity, audience, identity
Misunderstanding #4 OAuth does not do authentication
ThanksCory Forsyth
@banticLinks
• Torii: https://github.com/vestorly/torii • OAuth 2 explanation • More curated links
Image Credits
• https://twitter.com/old_sound/status/670412302135500803/photo/1