Salesforce Developer Security Auth Openid Config
// 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).
page revision: 0, last edited: 01 Jan 2017 23:27