OAuth 2.0 Misconceptions

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