Secure server-to-server integration without real time user involvement. Client specifies user in a JSON web token (JWT) or SAML format XML assertion and proves its own identity by appending a signature. JWT Bearer token flow is Ideal for application which access sfdc only through API as there is no UI involved. For example ETL tools or middleware.
Additional requirements
- Client can manage private key of an X.509 certificate
- Certificate available to auth. server
- User authorisation has been provided
- Up to date security measures
What else to know
- Client secret not required
- Flows will not return refresh tokens
- Additional user claims can be included
- User authorisation mechanism is up to individual implementation. For Salesforce as auth. server, options are:
- Admin approved users are pre-authorized – If user assigned a profile / permission set associated with app, no need for them to approve for flow to be used
- All users may self-authorize – User must have approved at least once
OAuth 2.0 JWT Bearer Token Flow
- Ideal for application which access sfdc only through API as there is no UI involved. For example ETL tools or middleware.
- A JSON Web Token (JWT) enables identity and security information to be shared across security domains.
- JWT is basically a JSON file consisting of a header and claims object, where the header contains the signature algorithm and the claims object contains specific information such as the username and consumer key. At a high level, you will then sign the JSON object with the private key of your certificate and send the JWT to Salesforce to obtain an access token.
- When a client wants to use this flow, posts an access token request that includes a JWT to Salesforce’s OAuth token endpoint. Salesforce authenticates the authorized app through a digital signature that is applied to the JWT.
- Digital certificates are required in this flow. Upload certificate (X509 ) to connected app which will be used to authenticate JSON web tokens.
- External application send request for access token by passing JWT token in body. SFDC server validate JWT and return access token to external app.
- No refresh token is returned in this flow. So if access token expires then send request to generate access token again.
What else to know – JWT Bearer
- JWT attributes:
- aud = Auth server identifier (for Salesforce, login URL)
- iss = Client identifier (for Salesforce, client id)
- sub = User identifier (for Salesforce, username)
- exp
- Used in SFDX CLI authorisation
- Available for named credentials callouts
OAuth 2.0 SAML Bearer Assertion Flow
- A SAML assertion is an XML security token issued by an identity provider and consumed by a service provider.
- The external app or client isn’t required to store client_secret.
- If you use active directory or LDAP as identity provider, then you will use SAML assertion from your SSO flow to obtain an access token to Salesforce.
- This flow used SAML assertion (XML token generated by Identity provide) and applied digital signature to it using certificates.
- In connected app, you upload this certificate (X509 ) containing private key. This key should be used while signing SAML asseration(base 64 encoded).
- The SAML assertion is posted to the OAuth token endpoint, which in turn processes the assertion and issues an access_token based on prior approval of the app(users are pre- authorized in connected app).
- This flow also return only access token not refresh token
What else to know – SAML Assertion Bearer
- SAML assertion is XML (Base64 encoded for auth. server)
- SAML attributes:
- Audience = auth. server identifier
- Issuer = issuing entity. For Salesforce, this
- must be the client app’s client_id
- Subject = User
- General SAML validations must be implemented by auth. Server
Recording
Considerations for choosing JWT / SAML assertion bearer
- Best practice for server to server OAuth
- Ideal flow for continuous integration, middleware, org to org integration, integration with public web site and many other use cases where real time user interaction not desirable
- Initial approval must be considered
