OAuth (Open Authorization) is an open-standard protocol for authorization that allows applications to access user information from a provider without the need to share user credentials. Salesforce supports several OAuth 2.0 grant types to facilitate different authentication and authorization scenarios. Below, we’ll discuss each of these grant types and provide examples for each.
- Web Server (Authorization Code) Flow
The Web Server Flow is suitable for applications that can securely store the client secret and can interact with the user’s browser. It is considered one of the most secure flows as the client secret never gets exposed to the end-user. This flow consists of the following steps:
a. Redirect the user to Salesforce’s authorization endpoint, where they will authenticate and grant access to your application. b. Salesforce sends an authorization code to your application’s redirect URI. c. Your application exchanges the authorization code for an access token and a refresh token by making a server-side request.
Example: A web application accessing Salesforce data on behalf of the user.
- User-Agent (Implicit) Flow
The User-Agent Flow is suitable for applications that cannot store the client secret securely, such as mobile applications or single-page web applications. The access token is directly issued without the need for an intermediate authorization code. Note that this flow does not support refresh tokens.
a. Redirect the user to Salesforce’s authorization endpoint, where they will authenticate and grant access to your application. b. Salesforce sends the access token directly to your application’s redirect URI.
Example: A mobile app that accesses Salesforce data on behalf of the user.
- JWT Bearer Token Flow
The JWT Bearer Token Flow is suitable for server-to-server authentication scenarios where a client application needs to access Salesforce on behalf of a user or a system account. Instead of an authorization code, the client application generates a JSON Web Token (JWT) and signs it with a private key. Salesforce validates the token and issues an access token in response.
Example: An application that periodically syncs data between Salesforce and an external system.
- Device Flow
The Device Flow is designed for applications running on devices with limited input or display capabilities, such as smart TVs or CLI applications. In this flow, the client application directs the user to a verification URL on a separate device (e.g., a mobile phone or computer) to complete the authentication process.
a. The client application requests a device code from Salesforce. b. The user is directed to a verification URL where they enter the device code. c. The client application polls Salesforce for an access token until the user completes the authentication process.
Example: A CLI tool that interacts with Salesforce data.
- Username-Password Flow
The Username-Password Flow, also known as the Resource Owner Password Credentials Flow, is suitable for situations where the user’s credentials are directly collected by the client application. This flow is not recommended for most applications, as it involves storing user credentials and is inherently less secure than other OAuth flows.
a. The client application sends a request containing the user’s credentials (username and password) and the client credentials (client ID and secret) to Salesforce. b. Salesforce validates the credentials and returns an access token and a refresh token.
Example: A test or debugging tool that needs direct access to Salesforce APIs.
Each of these OAuth protocols caters to different use cases and application architectures. While implementing Salesforce OAuth, carefully consider the security implications and choose the most appropriate flow for your specific application.