Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OAuth2 Primer

OAuth2 Primer

Slides from the tech talk at Marqeta HQ.

Manish Pandit

March 19, 2018
Tweet

More Decks by Manish Pandit

Other Decks in Technology

Transcript

  1. But... I do not want to give my Fidelity password

    to TurboTax I do not want TurboTax to pull anything other than trades I want the ability to revoke TurboTax’s access to my Fidelity Account
  2. So.. Access Keys Whitelisting HTTP Basic Screen Scraping with stored

    credentials Wide open access/No authorization
  3. And there is more.. Mobile IoT Devices Service to Service

    Client-Server Applications Rich Client Applications
  4. Need for.. A secure standard for access authorization without the

    password leaving the site where the protected data is. Short-lived tokens in lieu of passwords to access information. A standard that works across all the API access patterns.
  5. OAuth 2.0 OAuth is an open standard for access delegation,

    commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. (Wikipedia) OAuth 2.0 relies on HTTP over TLS OAuth is an authorization protocol, and NOT an authentication protocol. * I still have bad dreams about OAuth 1.0 and 1.0a
  6. Terminology The OAuth spec outlines the basic terms that build

    upon the standard. • Resource Owner • Resource Server • Client • Authorization Server
  7. Connecting the dots Resource Owner is the user whose resources

    (data) exists on a Resource Server. The Resource Owner grants access to a Client to access these resources, by authorizing access to those resources on an Authorization Server where his identity exists and can be authenticated. The Client then gets credentials from the Authorization Server that can be used on the Resource Owner’s behalf to access the resources on the Resource Server.
  8. Authorization Examples A Twitter desktop client posting tweets on your

    behalf MyFitnessPal getting your Step Count from your Fitbit Account Turbotax getting your trades from your Fidelity Account Instacart Servers calling Marqeta’s API Facebook iOS app accessing your Facebook account Single Page App (RCA) accessing your News Aggregator
  9. Client ID and Client Secret Identify the client which could

    be an web application, a single page app, a native mobile app, or a server
  10. Access Tokens Short lived (hours, days, weeks, months?), bearer tokens

    that the client can use to act on behalf of the resource owner.
  11. Refresh Tokens Long lived tokens, used to request a new

    access token upon expiry of the current one, without Resource Owner intervention.
  12. Scope Scopes define the which resources can be accessed by

    the client using the access token. Scopes can be sliced and diced in many ways - Read vs. Write, Functionality based, Default, etc. Be careful defining them - you’ll end up with an LDAP ACLs. Scopes <> ACL.
  13. Authorization Code Grant For client/server web applications, also known as

    delegated authentication. Also known as 3-legged OAuth. Quiz - Guess the 3 legs
  14. Authorization Code Grant Flow 1. The client redirects the resource

    owner to the authorization server by passing in the response_type=code, redirect_uri, scope, and client_id. 2. The authorization server asks the resource owner for his credentials, MFA may be performed here. 3. The authorization server asks the resource owner to pick scopes that the client will be authorized for. 4. Upon the resource owner granting access, the authorization server sends a short lived authorization code to the redirect_uri 5. The client uses this authorization code to do a POST on the authorization server, passing in client_id, client_secret, and grant_type=authorization_code. 6. The client receives a refresh token and and access token.
  15. Implicit Grant For Single Page Apps, or Desktop Clients, or

    Browser Extensions.. There is no client_secret since the client cannot keep the secret. A simplified version of Authorization Code Grant. A refresh token is not returned in the response. Never, ever used in Financial Systems.
  16. Implicit Grant Flow 1. Client redirects the resource owner to

    the authorization URL same as Authorization Code Flow, except response_type is token (vs. code), and grant_type is not passed. 2. Upon the access being granted by the resource owner, an Access Token is provided to the client.
  17. Resource Owner Password Grant For fully trusted clients, like Native

    Mobile Apps provided by the Resource Server who is also the Identity Server. The only grant type where a user’s credentials are passed in the token request. Also known as Password Grant
  18. Resource Owner Password Grant Flow 1. Client sends request to

    the Authorization server as a POST with grant_type=password, client_id, client_secret, scope, username, and password. 2. The Authorization Server responds with an access token and a refresh token.
  19. Client Credentials Grant For server to service, or machine to

    machine, or service to service call. There is no identity involved. Also known as 2-legged OAuth. A refresh token is not returned. Simplest of all grant types. Additional security via whitelisting and firewalling can be implemented.
  20. Client Credentials Grant Flow 1. Client sends a POST request

    to the authorization server with client_id, client_secret, grant_type=client_credentials and scope. 2. Authorization server returns an access token to the client.
  21. References The OAuth2 Spec, RFC 6749 https://tools.ietf.org/html/rfc6749 The OAuth Bible

    http://oauthbible.com/ A Guide to OAuth2 Grant Types https://alexbilbie.com/guide-to-oauth-2-grants/