Some common misconceptions and misunderstandings about OAuth 2.0

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