JWT / SAML Assertion Bearer Flows

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

Further Learning

• Authorisation Code With Secret (Web Server flow)
• Implicit Grant (User-Agent) Flow
• Authorisation Code with PKCE Flow