7. 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
9. And there is more..
Mobile
IoT Devices
Service to Service
Client-Server Applications
Rich Client Applications
10. 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.
11.
12. 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
15. Terminology
The OAuth spec outlines the basic terms that build upon the standard.
● Resource Owner
● Resource Server
● Client
● Authorization Server
16. 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.
17. 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
19. 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
20. Grant Type
Steps that define the authorization protocol, resulting in an access token.
21. Access Tokens
Short lived (hours, days, weeks, months?), bearer tokens that the client can use
to act on behalf of the resource owner.
22. Refresh Tokens
Long lived tokens, used to request a new access token upon expiry of the
current one, without Resource Owner intervention.
23. 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.
24. Authorization Code Grant
For client/server web applications, also known as delegated authentication.
Also known as 3-legged OAuth.
Quiz - Guess the 3 legs
25. 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.
27. 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.
28. 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.
29. 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
30. 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.
31. 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.
32. 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.
35. 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/
