This document discusses common misconceptions about OAuth 2.0. It clarifies that while OAuth 2.0 is an authorization framework, it does not directly provide authentication. It also explains differences between access tokens and refresh tokens, and notes that bearer tokens issued to different clients are not equal. Additionally, it clarifies the differences between authorization code flow and implicit grant flow.

1. Misconceptions of
OAuth 2.0

2. Cory Forsyth
@bantic

3. 201 Created
Consultants in NewYork City

4. Logan, UT

5. “A set of clean abstractions for authentication in Ember.js”

6. OAuth
a short intro

7. 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

8. 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

9. OAuth
• 1.0:
• A protocol
• 2.0:
• “Simpler”
• Less secure?
• A framework

10. OAuth Love Triangle
Resource Owner
(user)
Resource /
Authorization
Server
(my-pix.com)
Client
(print-me.com)
visits1 directs browser to2
consent screen
3
redirects to,
with authz in url
4

11. OAuth Love Triangle
User e.g. Google+
your ember app
visits1 opens popup to2
consent screen
3
redirects to,
with authz in url
4

12. 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.)

13. 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

14. OAuth 2 Flows
• Authorization Code Grant
• Implicit Grant
• 2 others, less important

15. 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&
…=…

16. 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

17. 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

18. 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

19. Misunderstanding #1
Access vs Bearer Tokens

20. • 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

21. 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)

22. 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:

23. 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

24. 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

25. Misunderstanding #3
Refresh Tokens “refresh” nothing
• “You cannot refresh an implicit grant token”
• “You can only refresh an access token from
Authorization Code grant”

26. Misunderstanding #3
Refresh Tokens “refresh” nothing
• “You cannot refresh an implicit grant token”
• “You can only refresh an access token from
Authorization Code grant”

27. Misunderstanding #3
Refresh Tokens “refresh” nothing

28. Misunderstanding #4
OAuth does not do authentication
• authentication: Who are you?
• authorization: What are you allowed to do?
• OAuth 2.0: An Authorization Framework

29. 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?

30. 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

31. 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

32. Misunderstanding #4
OAuth does not do authentication

33. Thanks
Cory Forsyth
@bantic
Links
• Torii: https://github.com/vestorly/torii
• OAuth 2 explanation
• More curated links
Image Credits
• https://twitter.com/old_sound/status/670412302135500803/photo/1