oAuth2.0 Flows

Web server Flow

Here we have 4 tokens, Resource owner-> Client1 ->Auth Server-> Resource Server

Used by Apps that are hosted on a secure server

Main aspect is to be able to protect the consumer secret

Using the Authorization Code Grant

Commonly used oAuth Flow.

Optimized for Server side apps.

There are 2 servers — Auth Server and Resource Server

On Login , we(resource Owner/Client) request for an Authorization Code request from the Auth server

The Auth Server response is shared by Auth Server.

The resource Owner/Client used the Auth Code and requests for Access Tokens to the Auth Server. This is an extra level of Security.

The Auth Server responds with an Access Token( + Refresh Token) . Depends on how oAuth server is setup, they have the ability to automatically share the refresh token or we may have to request for a new one by making a call.

The Resource Server is now called using the Call API Access Token.

The Resource Server responses with data.

When the Access Token expires, then the client will request for new access token using the refresh token.

The cycle continues again.

User Agent

Here we have 4 tokens, Resource owner-> Client1 ->Auth Server-> Resource Server

Not an ideal scenario.

Client is now an Angular JS token. Used for FE apps, just like 2 apex classes interacting with one another and using a Heroku page to fetch and display Salesforce data.

There is no backend to keep the information secure. Hence there is no Access Code request in this one like the Web Server.

The main difference between this and the web Server is that the first step where the access code was requested which in turn was used to fetch the access token from Auth Server.

In User Agent flow there is direct request of Access Token and no concept of Access Code first. Everything else remains the same. Hence one level of security is missing.

Possible Usecases — If there is a Heroku page or an Angular JS App that needs some information from Salesforce but doesn’t want to store it, just display or allow to create new ones, the user agent flow will be used.

As there is no backend there is no place to save the access code or the data.

Relies on JS or browser, resides on users device or computer.

Ideal scenario where we do not want to save the data to Salesforce, display directly.

UserName and Password

Here we have 4 tokens, Resource owner-> Client1 ->Auth Server-> Resource Server

The resource owner shares the username & password to the Client.

The Client then saves the username & password to request the access token. The same process follows once we have the access token. (Resource owner password Grant)

The client already had this username and password for this service as the client and the service are the same thing.

Possible Scenarios — The Salesforce mobile app is logged in using the username and password. but this mobile app needs to retrieve the information from Salesforce.com. Hence it uses my username and password to request for an access token at the Salesforce.com( Auth Server). Since Salesforce mobile app and Salesforce.com are the same thing, it is a trust relationship.

The user never gave direct authorization, the app is saving and authorising implicitly.

Device Authentication

Here we have 5 tokens, REsource owner-> Client1 (Hotel TV)-> Client2 (Phone device)->Auth Server-> Resource Server

Auth code request is sent to Auth server.

The Auth Server returns the user code, device code, verification URL t o Client1.

The Client1 send this display code and URL to Resource Owner.

Now we access the Client2 (phone) , access URL and enter the code.

The Client1 keeps pulling the access token, it polls server access with access token request..

Now the Auth Token is released by the Auth Server which is used by Client1 to display.

Use Case — For logging in to your netflix account from the hotel TV, you will have to enter the username and password using the TV remote.

Device authentication comes into play when the Netflix app will give you an option to connect your device(mobile device) via an access code or URL. On accessing the URL on your mobile device your login is authenticated on the TV.

This is somewhat similar to web Whatsapp.

JWT Bearer Token

This is a Mini flow. Can be used in any of the other big flows.

Client requests auth Server for access token using a JWT Bearer Token.

Same flow as we saw before.

Auth Server recognises and sends access token(+refresh token) back.

Adds an additional layer of security due to JWT bearer token encryption.

One caveat -If we are using a web server flow to request an access token with a JWT bearer token, then we do not get the refresh token back.

Asset Token

Same Flow .

Exchange Auth Code for access token using Access Token between Client and Auth Server.

Extra level of security.

SAML Bearer Assertion

Same Flow .

Exchange Auth Token using SAML Token between Client and Auth Server.

Extra level of security.

Adds SAML Assertion to the request for Auth Token

Usecases — Uses previous obtained authorization which was obtained through SSO .

SAML Assertion

Same as SAML Bearer Assertion except only used when SF talks to itself. It’s inside a single app. Do not need a Connected App.