...
The most used flow with Salesforce. Where a user logs in. Eg via a mobile app, or a third party app like Workbench
Steps
Go to Workbench and login
Workbench redirects you to the Salesforce login screen
You log in to Salesforce
You are prompted to approve sharing data you have access to in Salesforce to Workbench via the scopes. Be aware of the scopes that are requested
Workbench receives a callback from Salesforce with the access token. The callback includes
access_token - the Salesforce session id
Identity URL - id - user details. Basically the URL of the user record
issued_at - date and time the access token was issued (unix time)
token_type - eg bearer
instance_url - your Salesforce instance URL
signature - client secret key, encoded
scope - eg id+api+refresh_token
state -
JWT Flow
SAML Bearer Assertion Flow
SAML Assertion
XML basedEnables applications to reuse an existing authorisation by supplying a SAML assertion
I don't know when it would be used but it seems older than JWT but similar in that it doesn't require the user to intervene.
Is an XML security token issued by an identity provider (another app) and consumed by a service provider (Salesforce)
External app is already authorised. The user is previously authorised. (eg by being allowed to use this connected app).
The user needs to click allow
Can only be used after the consumer has received a refresh token from the authorisation
Need to to set a long expiry ??? for the session timeout
The user is authorising this connected app to get the token it needs to do its thing.
Authentication by digital signature (certificate)
Matched to the certificate stored against the Connected App in Salesforce. X.509 certificate.
Not required to store the refresh token. Refresh token never issued.
Client secret not required (because we have the certificate)
It's similar to a refresh token
Steps
Create the connected app
It needs the refresh token scope
Upload the certificate. This is the public key for the app.
The client id is created by the connected app.
Client app generates SAML assertion and signs it with their private key.
Hit the token endpoint POST and send the SAML assertion to that endpoint
Issuer - client_id of the connected app
Audience - login.salesforce.com
Recipient (the /oauth2/token endpoint)
Subject - Salesforce User Name. (SAML configuration in the connected app)
SAML Assertion Base64 encoded and signed using RSA and SHA-1 or SHA-256
Grant_type:saml2-bearer
Token endpoint validates the certificate and the audience, issuer and subject. These are parameters on the endpoint.
Salesforce issues acess token (session id)
Token type bearer
Scope can't be specified in the assertion because it's set uo on the connected app
...