OAuth2

Enterprise authentication solution

SAML protocol: Single sign on(SSO) across sites.

Legacy authentication solution

Simple login: Forms and cookes.

What problem does Oauth2 address

• Delegated authorization problem.

Oauth2 flow

• Click on login with Gmail.
• Redirected to accounts.google.com and prompted to login.
• After logging in, prompt the user if they want to share public profile and contacts with Yelp?
• If user clicks Yes, then he is redirected back to application, at a specific place called 'redirect uri'.

Oauth2 terminology

• Resource owner: The user clicking yes at prompt.
• Client: The application for eg. Yelp.
• Authorization server: System which user uses to say Yes, for eg. accounts.google.com
• Resource server: The API or resources which the client want access to. For eg Google contacts API.
• Authorization grant: Proves that resource owner/user has clicked yes.
• Redirect Uri/callback: Auth flow goes here when "user" clicks yes.
• Access token: Used by client to get access to resource server.
• Scope: Authorization server has a list of scopes for eg contact-read, contact-write, profile-read etc.
• Consent:

Network security terminology:

• Back channel: Highly secure channel, for eg. from a backend server to resource server. The secret key/application id/ access token is never known to and sent from the front channel.
• Front channel: Less secure channel, for eg. browser. We cannot put a key in html or javascript of the web app as anyone can view the source. It is used to interact with the user or resource owner.

Oauth2 Flows

Oauth2 authorization code Flow

Note

• state is used to prevent CSRF.
• The client registers with authorization server and gets client ID and client secret which are later used in front and back channel communication respectively. It also has to specify redirect URI/Callback.

Starting the Oauth2 authorization code flow

Calling back

Exchange the code for access token

Access token from server

Use the access token

Identity use cases Pre 2014

Problems with Oauth2 Authentication

• Oauth2 was primarily designed for authorization. As there is no standard way of getting user's information.
• No standard way to get user's information.
• Every implementation is little different.
• No common set of scopes.

What OpenID connect adds

• ID token.
• UsertInfo endpoint for getting more user information.
• Standard set of scopes.
• Standardized implementation.

Identity use cases today (with openID)

OpenID stack

Oauth2 vs OpenID

OpenID connect authorization code flow

Starting OIDC flow

Exchange code for access token and ID token

Auth server returns access and ID tokens

ID token (aka JWT) in OpenID

ID token in code/json

ID Token(JWT) in debugger

Calling user info endpoint

Oauth2 Implicit flow

Which authorization grant type (flow) to use

Server flow example

Mobile flow example

Authorization code with PKCE part1

Authorization code with PKCE part2

Implicit Flow example

Oauth discovery

Third party(SAML) integration example

Token validation

• Local validation: The fast way.
  • Check expiration timestamp.
  • Validate cryptographic signature.
• Introspection: The strong way.

Keeping user signed in

For both local validation and introspection, the token is invalid once it expires

• If there is user at keyboard, just redirect him to authorization server.
• If there is no user(automated tasks), request a refresh token(offline scope).

Note: Using okta you can spin your own authorization server in the cloud.