Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OAuth 2.0 Misconceptions

Some common misconceptions and misunderstandings about OAuth 2.0

  • Be the first to comment

OAuth 2.0 Misconceptions

  1. 1. Misconceptions of OAuth 2.0
  2. 2. Cory Forsyth @bantic
  3. 3. 201 Created Consultants in NewYork City
  4. 4. Logan, UT
  5. 5. “A set of clean abstractions for authentication in Ember.js”
  6. 6. OAuth a short intro
  7. 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. 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. 9. OAuth • 1.0: • A protocol • 2.0: • “Simpler” • Less secure? • A framework
  10. 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. 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. 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. 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. 14. OAuth 2 Flows • Authorization Code Grant • Implicit Grant • 2 others, less important
  15. 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. 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. 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. 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. 19. Misunderstanding #1 Access vs Bearer Tokens
  20. 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. 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. 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. 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. 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. 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. 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. 27. Misunderstanding #3 Refresh Tokens “refresh” nothing
  28. 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. 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. 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. 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. 32. Misunderstanding #4 OAuth does not do authentication
  33. 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

    Be the first to comment

    Login to see the comments

  • andysparsons

    Dec. 6, 2015

Some common misconceptions and misunderstandings about OAuth 2.0

Views

Total views

578

On Slideshare

0

From embeds

0

Number of embeds

3

Actions

Downloads

14

Shares

0

Comments

0

Likes

1

×