OAuth as a Standard
OAuth in Practice
Identity and Authorization
I want TurboTax to pull my trades from Fidelity
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
Screen Scraping with stored credentials
Wide open access/No authorization
And there is more..
Service to Service
Rich Client Applications
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.
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
The OAuth spec outlines the basic terms that build upon the standard.
● Resource Owner
● Resource Server
● 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
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 and Client Secret
Identify the client which could be an web application, a single page app, a native
mobile app, or a server
Steps that define the authorization protocol, resulting in an access token.
Short lived (hours, days, weeks, months?), bearer tokens that the client can use
to act on behalf of the resource owner.
Long lived tokens, used to request a new access token upon expiry of the
current one, without Resource Owner intervention.
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
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.
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
2. The Authorization Server responds with an access token and a refresh
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.