Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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

...