Authenticating Remote Access Application OAuth

Available in: All Editions

User Permissions Needed
To manage, create, edit, and delete OAuth applications: “Manage Remote Access”

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 the following authentication flows:
  • 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.
  • OAuth 2.0 user-agent—The user-agent authentication flow is used by client applications (consumers) residing in the user's device. This could be implemented in a browser using a scripting language such as JavaScript, or from a mobile device or a desktop application. These consumers cannot keep the client secret confidential.
  • 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 organization. You do not have to create a remote access application 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.
    Warning
    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.

OAuth 2.0 Endpoints

The three primary endpoints used with OAuth 2.0 are:
  • Authorization—https://login.salesforce.com/services/oauth2/authorize
  • Token—https://login.salesforce.com/services/oauth2/token
  • Revoke—https://login.salesforce.com/services/oauth2/revoke

See Revoking OAuth Tokens for details on revoking access.

For a Sandbox, use test.salesforce.com instead of login.salesforce.com.

© Copyright 2000–2013 salesforce.com, inc. All rights reserved.
Various trademarks held by their respective owners.