OAuth2 Primer Manish Pandit 03/19/2018 

No content

No content

No content

OAuth Primer The Need OAuth as a Standard OAuth in Practice 

Identity and Authorization I want TurboTax to pull my trades from Fidelity 

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 

So.. Access Keys Whitelisting HTTP Basic Screen Scraping with stored credentials Wide open access/No authorization 

And there is more.. Mobile IoT Devices Service to Service Client-Server Applications Rich Client Applications 

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. 

No content

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 

..and many, many more! 

Coming soon.. 

Terminology The OAuth spec outlines the basic terms that build upon the standard. ● Resource Owner ● Resource Server ● Client ● Authorization Server 

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. 

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 

OAuth 2.0 Constructs Client ID Client Secret Scope Grant Type Access Token Refresh Token 

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 

Grant Type Steps that define the authorization protocol, resulting in an access token. 

Access Tokens Short lived (hours, days, weeks, months?), bearer tokens that the client can use to act on behalf of the resource owner. 

Refresh Tokens Long lived tokens, used to request a new access token upon expiry of the current one, without Resource Owner intervention. 

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. 

Authorization Code Grant For client/server web applications, also known as delegated authentication. Also known as 3-legged OAuth. Quiz - Guess the 3 legs 

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. 

Demo – CapitalOne Rewards 

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. 

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. 

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 

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. 

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. 

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. 

Demo – CapitalOne Credit Offers 

Source: https://auth0.com/docs/api-auth/which-oauth-flow-to-use 

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/