What are different OAuth Authorization Flows in Salesforce?

OAuth authorization flows grant a client application restricted access to protected resources.

Salesforce offers multiple OAuth authorization flows. As a Salesforce developer, you can choose from several OAuth authorization flows considering the use cases.

Each OAuth flow offers a different process for approving access to a client app, but in general the flows consist of three main steps.

1)      A client app requests access to a protected resource.

2)      In response, an authorizing server grants access tokens to the client app.

3)      A resource server then validates these access tokens and approves access to the protected resource.

Some of the important OAuth authorization flows are mentioned below.

1)      OAuth 2.0 Web Server Flow for Web App Integration

This flow is used to integrate an external web app with the Salesforce API, it implements the OAuth 2.0 authorization code grant type. With this flow, the server hosting the web app must be able to protect the connected app’s identity, defined by the client ID and client secret.

2)      OAuth 2.0 User-Agent Flow for Desktop or Mobile App Integration

With the OAuth 2.0 user-agent flow, users authorize a desktop or mobile app to access data by using an external or embedded browser. Client apps running in a browser using a scripting language such as JavaScript can also use this flow. This flow uses the OAuth 2.0 implicit grant type.

3)      OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration

Sometimes you want to authorize servers to access data without interactively logging in each time the servers exchange information. For these cases, you can use the OAuth 2.0 JSON Web Token (JWT) bearer flow. This flow uses a certificate to sign the JWT request and doesn’t require explicit user interaction. However, this flow does require prior approval of the client app.

4)      OAuth 2.0 Client Credentials Flow for Server-to-Server Integration

In this flow, the client app exchanges its client credentials defined in the connected app—its consumer key and consumer secret—for an access token. This flow eliminates the need for explicit user interaction which is needed in username-password flow, though it does require you to specify an integration user to run the integration. You can use this flow as a more secure alternative to the OAuth 2.0 username-password flow.

5)      OAuth 2.0 Username-Password Flow for Special Scenarios

You can use the username-password flow to authorize a client via a connected app that already has the user’s credentials. It is not a recommended flow because it passes credentials back and forth. This should be used only if there’s a high degree of trust between the resource owner and the client. In these cases, set user permissions to minimize access and protect stored credentials from unauthorized access.

Note: Some flows have important security considerations. For example, when using the web server flow, you must store the client secret securely. We recommend avoiding the user-agent and username-password flows because they transmit credentials.

We will see each of the above mentioned flows in details in upcoming articles.