Salesforce Developer Security Auth Openid Config

salesforce-developer-security

// Salesforce - Developer - Security - OpenID - Configuring OpenID Connect:

If you're planning to use Salesforce as an OpenID Provider, you'll need to 
define a connected app in your organization. Since an OpenID Connect app is just 
an OAuth 2.0 connected app with the OpenID scope selected, everything you need 
to know is in the 'Digging Deeper into OAuth 2.0' article.

Once you've defined your connected app, and you have your client id and client 
secret, you're all set to integrate. OpenID Connect libraries exist for a wide 
variety of languages; but it's useful to have an idea of the underlying protocol.

The sequence starts (1) with the end-user making some request of the client - 
for example, clicking a 'Login with Salesforce' button. The client redirects (2) 
the end-user's browser to a URL at the authorization server of the following 
form:

https://login.salesforce.com/services/oauth2/authorize?response_type=code&
client_id=<your_client_id>&redirect_uri=<your_redirect_uri>

The following parameters are required (all must be URL encoded):

1. response_type:  Must be set to code to request an authorization code.

2. client_id: Your application's client identifier (consumer key in Connected 
   App Detail).

3. redirect_uri: The end user's browser will be redirected to this URI with the 
   authorization code. This must match your application's configured callback 
   URL.

Optional parameters can be defined as described in Web Server flow to tailor the 
login page to the user's device type, avoid user interaction etc.

The user will be prompted to authenticate (3) and, if they have not already done 
so, authorize the client application. If OpenID scope is requested, the user is 
prompted to 'allow access to their unique identifier'.

On successful authorization, the user's browser is redirected back to the 
redirect URI at the client application (4), with a URL of the form:

https://app.example.com/oauth_callback?code=aWe...c4w%3D%3D&state=
<whatever_you_sent_in_step_2>

The client application can now extract the authorization code from its URL 
parameter and send a direct POST request (5) to the authorization server with 
URL https://login.salesforce.com/services/oauth2/token and payload of the form

code=aWe...c4w==&grant_type=authorization_code&client_id=<your_client_id>
&client_secret=<your_client_secret>&redirect_uri=<your_redirect_uri>

The following parameters are required (again, URL encoded):

1. code: The value returned by the authorization server in the previous step.

2. grant_type: Set this to authorization_code.

3. client_id: Your application's client identifier.

4. client_secret: Your application's client secret (consumer secret in the 
   connected app detail page).

5. client_assertion: Instead of passing in client_secret you can choose to 
   provide a client_assertion and client_assertion_type. If a client_secret 
   parameter is not provided, Salesforce checks for the client_assertion and 
   client_assertion_type automatically.  The value of client_assertion must be 
   a typical JWT bearer token, signed with the private key associated with the 
   OAuth consumer’s uploaded certificate. Only the RS256 algorithm is currently 
   supported. For more information on using client_assertion, see the OpenID 
   Connect specifications for the private_key_jwt client authentication method.

6. client_assertion_type: Provide this value when using the client_assertion 
   parameter.  he value of client_assertion_type must be:
   </code>urn:ietf:params:oauth:client-assertion-type:jwt-bearer</code>

7. redirect_uri: Again, this must match your application's configuration.

If you're familiar with OAuth 2.0, you've probably noticed that, with the 
exception of the openid scope value, the OpenID Connect Basic Client Profile is 
so far identical to the OAuth 2.0 authorization code grant type ('web server 
flow'). This is intentional - OpenID Connect was designed to leverage existing 
identity infrastructure.

Here is the key difference from 'vanilla' OAuth 2.0: the authorization server's 
response (6) contains an ID token.

The client app can decode the id token to obtain a claims set.

To guard against impersonation attacks, the client app must now verify that the 
ID token's aud parameter matches its own client id.

Now that the client app has the ID token, it knows that the issuer authenticated 
the end-user for the purpose of accessing that client app. The client app also 
has an access token to access resources at the authorization server, including 
the user profile service (known in the protocol specification as the UserInfo 
Endpoint).
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License