Authenticating Remote Access Application OAuth

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 accessSalesforce, 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.

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

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

Setting Up Authentication with OAuth 2.0

Setting up OAuth 2.0 requires some configuration in the user interface and in other locations. If any of the steps are unfamiliar, you can consult the Force.com REST API Developer’s Guide or OAuth 2.0 documentation.

In Salesforce, from Setup, click Create | Apps. Click New in the Connected Apps related list to create a new connected app.

1. The Callback URL you supply here is the same as your Web application's callback URL. Usually it’s a servlet if you work with Java. It must be secure: http:// doesn’t work, only https://. For development environments, the callback URL is similar to https://my-website/_callback. When you click Save, the Consumer Key is created and displayed, and a Consumer Secret is created (click the link to reveal it).
   Note

   The OAuth 2.0 specification uses “client” instead of “consumer.” Salesforce supports OAuth 2.0.
   The values here correspond to the following values in the sample code in the rest of this procedure:
   • client_id is the Consumer Key
   • client_secret is the Consumer Secret
   • redirect_uri is the Callback URL.
   An additional value you must specify is: the grant_type. For OAuth 2.0 callbacks, the value is authorization_code as shown in the sample. 
   If the value of client_id (or consumer key) and client_secret (or consumer secret) are valid, Salesforce sends a callback to the URI specified inredirect_uri that contains a value for access_token.
   
   
   For more information about these parameters, 
   see http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com.