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

Bearer Flow

  • SAML Assertion

  • XML based

  • External app is already authorised and just need the token . 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???

  • The user is authorising this connected app to get the token it needs to do its thing.

  • Authentication by digital signature . What does this mean? (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.

    • 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

      • Subject - Salesforce User Name. (SAML configuration in the connected app)

      • SAML Assertion Base64 encoded

        • 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

Roles

  • Resource Owner - the user accessing the service. (yep this one sounds wrong)

    • Accesses the application

    • Authenticates against the authorisation server

  • Client - the application / service that is being accessed.

    • Accesses data from the resource server after an Access Token is issued from the authorisation server. Lasts the length of the session.

    • Two types of Clients - Secure and Public

    • Consumer Key is used to identify itself to the Resource Server

    • Refresh token is used to request a new Access Token

  • Resource Server - the server that hosts the application

    • Provides data to the application

    • Delegates to the the authorisation server to issue the token

  • Authorisation Server - usually the resource server, but can be separate.

    • Accepts the request from the resource owner to authenticate

    • Issues the token so the user can access the application

...