Salesforce supports various OAuth 2.0 grant types for different use cases. Here’s a list of the most common grant types, along with explanations and examples of when it might make sense to use them:
- Authorization Code Grant (Web Server Flow): This is the most common grant type for server-side web applications. It allows the app to request an authorization code from Salesforce, which can be exchanged for an access token and a refresh token. The app can then use the access token to call Salesforce APIs on behalf of the end user.
Example: A web-based project management application that needs to access a user’s Salesforce data, such as tasks and events, to provide an integrated experience.
- Implicit Grant (User-Agent Flow): This grant type is intended for client-side apps, like single-page applications (SPAs), where the app runs in the user’s browser and has no server-side component. The app directly receives an access token after the user authorizes it.
Example: A JavaScript-based Salesforce data visualization application running in the user’s browser, which needs to access Salesforce data via API calls.
- Resource Owner Password Credentials Grant (Username-Password Flow): In this flow, the user provides their Salesforce username and password directly to the app, which then exchanges them for an access token. This grant type is less secure, as it requires users to share their credentials with the app, and it’s generally not recommended for most use cases.
Example: A command-line tool that requires access to a user’s Salesforce account for a one-time operation, like exporting data or performing a specific task.
- JWT Bearer Token Grant (JWT Flow): This grant type is suitable for server-to-server integrations, where the app has its own identity and doesn’t act on behalf of an end user. The app generates a JSON Web Token (JWT) and signs it with a private key. Salesforce then verifies the token and issues an access token.
Example: An integration between an HR system and Salesforce, where the HR system needs to synchronize employee data without direct user intervention.
- Refresh Token Grant: This grant type is used to obtain a new access token when the existing one expires, without requiring the user to re-authenticate. It’s typically used in conjunction with the Authorization Code Grant, as the refresh token is issued alongside the initial access token.
Example: A web application that has already authenticated the user using the Authorization Code Grant, but needs to maintain access to the user’s Salesforce data even after the initial access token expires.
- SAML Bearer Assertion Grant (SAML Flow): This grant type is used when Salesforce acts as a service provider in a Single Sign-On (SSO) scenario, and another system acts as the identity provider (IdP). The app generates a SAML assertion, which is then exchanged for an access token.
Example: An organization has a centralized identity provider for all its applications, and wants to use this IdP to authenticate users and provide access to Salesforce.