Explore Salesforce OAuth Authorization Flows and Its Use Cases

Have you authorized an application to access Salesforce without giving your credentials to that application? Then, you must have used a Salesforce OAuth authorization flow. OAuth is a standard for authorization. Salesforce uses several OAuth flows, and all these flows have the following three steps in general. 

1. The client app requests access to a protected resource in Salesforce
2. The Salesforce authorizing server, in response to the request, sends the access token back to the client app
3. The resource server (Salesforce) validates the access token and approves access to the protected resource

It is also important to understand the difference between authentication and authorization. Authentication is about verifying WHO you are, whereas authorization is about verifying WHAT you can do. A username and password are the most common type of authentication. Profiles or permission sets are associated with authorization. 

OAuth Roles

All OAuth flows have the following roles in action. 

1. Resource owner: The resource owner is the user who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted (e.g., read or write access).
2. Resource server: Server or application hosting protected data or functionality. 
3. Authorization server: Server or application that issues access tokens and grants. 
4. Client: Application requesting access to protected resources on behalf of the resource owner. 

OAuth Components

Following are the key components of an OAuth flow. 

1. Consumer key: The key used by the consumer to identify itself to the resource server. 
2. Access token: An access token represents a user’s permission for the client to access their data. It is used to get access to the resources. 
3. Refresh token: Refresh token is used to request a new access token when an access token has expired. 
4. Authorization code: An authorization code is a short-lived code that represents the access granted by the end user. This code is used to obtain access tokens and refresh tokens. 
5. Scope: Scope defines the level of access. Some examples of scope are API, full, refresh token, etc. 

Almost all OAuth flows need a connected app set up in Salesforce. 

Connected App

The connected app defines the entry point when an external application is integrated with Salesforce. It controls how the application interacts with Salesforce, ensuring secure authorization, authentication, and single sign-on (SSO) capabilities. When you create a connected app in Salesforce to integrate an external application with your Salesforce API, you can configure the connected app using OAuth authorization settings. The connected app also allows Salesforce admins to manage access to it by defining the profiles and permission sets associated with the connected app. Salesforce admins can also audit the connected app usage. 

OAuth Flows

Let us look into different OAuth flows. 

Scenario 1

The client application cannot be trusted because it cannot protect the client secret issued by Salesforce's connected app. 

In this case, you can go for OAuth 2.0 User-Agent Flow. This flow is used for mobile or desktop app integration with Salesforce. Dataloader is a common example. 

Since the source code of these applications can be easily accessed by the user and client secrets can be exposed, user-agent flow is appropriate. In this flow, a user has to manually authenticate to Salesforce using their credentials and approve the partner app. After approval, an access token and refresh token are generated in this flow. 

Note that we don't use client secrets in this flow. 

Scenario 2

The client app is capable of protecting consumer secrets and can be trusted. 

In this case, you can use the OAuth2.0 Web-Server Authentication Flow. In this flow, we use client secret as an extra authorization parameter. Make sure that your client app can protect the client's secret while using this flow and that the user cannot manipulate the source code. In this flow, the user also has to manually log into Salesforce and approve the access. So, this flow is not recommended for server-server integration. A refresh token is generated in this flow as well. 

Scenario 3

The client app is an API-only application and wants to connect to Salesforce. 

You don't have a UI for the user to approve the access for the app. In this case, you can go for OAuth2.0 JWT Bearer Token Flow. This flow requires you to upload a certificate to the connected app that will be used to validate the token. You will also need to create a JWT token, which is a JSON file that has the digital signature details. The private key of the certificate uploaded to the connected app is used to sign the JWT token. This flow also requires prior approval of the client app. Prior approval can happen in one of the two ways. 

• Set your connected app policy to Admin approved users are pre-authorized, and use profiles and permission sets.
• Set your connected app policy to All users may self-authorize. You can use end-user approval and issuance of a refresh token. 

To request an access token, the client app posts a request to the token endpoint, which includes a JWT. Salesforce validates the JWT using the previously configured certificate. As long as JWT is valid and the client app has prior approval, Salesforce issues an access token. 

Details on how to generate a JWT token can be found here. 

If you have SSO enabled for your organization via an active directory or similar central access control system, you could use the SAML assertion from your SSO flow to generate an access token from Salesforce. This flow is called OAuth 2.0 SAML Bearer Assertion Flow. 

Similar to the JWT flow, we use a certificate to sign the SAML assertion. This certificate is uploaded to the connected app. In your post-call to the token endpoint

Scenario 4

The access token used by the client app is expired, and you don't want a user log in and approve the app every time.

You can use OAuth2.0 Refresh Token Flow to generate an access token without a user manually approving client app access. In this flow, you will send a refresh token to the token endpoint. But where do you get the refresh token? The refresh token is generated the first time when you use user-agent or web server flow. The client app can save this refresh token and can be used in this flow to regenerate the access token when the current token expires. 

Scenario 5

Client app runs on a device with limited input or display capability 

A device with limited input capability, such as a smart TV, wants to connect to Salesforce. In this case, you can use OAuth2.0 Device Authentication Flow. Users can connect these apps to Salesforce by accessing a browser on a device with advanced input capability, such as a mobile device. Users authenticate and authorize, while the app continuously polls the Salesforce token endpoint. Polling checks whether the user has authorized and Salesforce has issued an access token. 

Conclusion

There are various OAuth authorization flows you can use when you integrate external client applications into Salesforce. If your use case doesn't have issues in getting a user to manually authorize the client app, you can go for web server or user-agent flow. Both these flows issue a refresh token, which can be used to regenerate the access token upon expiration. If you have a server-server integration, you can go for JWT or SAML flow. If you are working with devices with limited input capabilities, you can go for device authentication flow, which involves users inputting user code in their desired browsers in a verification URL. There are a lot of other advanced flows available in Salesforce.