|Available in: Salesforce Classic|
|Available in: All Editions|
|To manage, create, edit, and delete OAuth applications:||“Manage Connected Apps”|
When a user requests their Salesforce data from within the external application (the consumer’s page), the user must be authenticated by Salesforce. There are several steps in each authentication flow, as dictated by the OAuth standard and what is trying to access Salesforce.
Salesforce supports OAuth versions 1.0A and 2.0
- OAuth 1.0.A—This version of OAuth has only one flow.
- OAuth 2.0 Web server—The web server authentication flow is used by applications that are hosted on a secure server. A critical aspect of the web server flow is that the server must be able to protect the consumer secret. You can also use code challenge and verifier values in the flow to prevent authorization code interception.
- OAuth 2.0 refresh token flow—After the consumer has been authorized for access, they can use a refresh token to get a new access token (session ID). This is only done after the consumer already has received a refresh token using either the Web server or user-agent flow.
- OAuth 2.0 JWT Bearer Token Flow—The OAuth 2.0 JWT bearer token flow defines how a JWT can be used to request an OAuth access token from Salesforce when a client wishes to utilize a previous authorization. Authentication of the authorized application is provided by a digital signature applied to the JWT.
- OAuth 2.0 SAML Bearer Assertion Flow—The OAuth 2.0 SAML bearer assertion flow defines how a SAML assertion can be used to request an OAuth access token when a client wishes to utilize a previous authorization. Authentication of the authorized application is provided by the digital signature applied to the SAML assertion.
- SAML assertion flow—The SAML assertion flow is an alternative for organizations that are currently using SAML to access Salesforce, and want to access the web services API the same way. The SAML assertion flow can only be used inside a single org. You don’t have to create a connected app to use this assertion flow.
- OAuth 2.0 username and password—The username-password authentication flow can be used to authenticate when the consumer already has the user’s credentials.
This OAuth authentication flow involves passing the user’s credentials back and forth. Use this authentication flow only when necessary. No refresh token will be issued.
For all authentication flows, if a user is asked to authorize access and instead clicks the link indicating they are not the currently signed in user, the current user is logged out and the authorization flow restarts with authenticating the user.
Users can authorize an application to access Salesforce more than once, for example, for both a laptop and a desktop computer. The default limit is five authorizations per application per user. If a user tries to grant access to an application more times than allowed by the organization limit, the least recently used access token for that application is revoked. Newer applications (using the OAuth 2.0 protocol) using the Web server flow are automatically approved for additional devices after the user has granted access once. The user-agent flow requires user approval every time.
OAuth 2.0 Endpoints
The three primary endpoints used with OAuth 2.0 are:
See Revoking OAuth Tokens for details on revoking access.
For a sandbox, use test.salesforce.com instead of yourDomain.salesforce.com.