Diagramme et processus de flux d'échange de jetons

Voici le scénario : Vous hébergez un portail client hors de Salesforce Platform. Pour vous assurer que les clients ont accès à toutes les informations dont ils ont besoin, vous avez intégré le portail à une variété d'applications et de microservices différents. Par exemple, vous utilisez une application tierce pour gérer les paiements et l'expédition, et vous utilisez Amazon Web Services pour gérer les données des clients. Vous ne souhaitez pas obliger les clients à se connecter à tous ces différents services. Par conséquent, vous utilisez également Okta en tant que fournisseur d'identité tiers. Ainsi, les clients peuvent se connecter à Okta et accéder à toutes les informations dont ils ont besoin dans votre portail.

Vous devez pouvoir gérer les requêtes de support dans le portail et vous savez que Salesforce peut faire le travail. Cependant, vous souhaitez vous assurer que les clients peuvent accéder aux informations de leur requête directement dans votre portail sans se connecter à Salesforce. En d'autres termes, vous souhaitez adapter Salesforce à votre système existant. C'est là qu'intervient le flux d'échange de jetons. Avec ce flux, vous pouvez vous assurer que les clients peuvent accéder à leurs données Salesforce lorsqu'ils se connectent à votre portail via Okta.

Pour comprendre comment le flux d'échange de jetons peut fournir cette expérience, examinons la séquence du flux. Pour une explication plus détaillée des requêtes et des réponses dans ce flux, consultez Configuration du flux d'échange de jetons.

Au démarrage du flux, supposons que l'utilisateur s'est déjà connecté au portail client (le client) via Okta (le fournisseur d'identité). Le client est intégré à Salesforce en utilisant l'infrastructure d'application cliente externe.

• (1) L'utilisateur demande l'accès aux ressources Salesforce protégées. Par exemple, dans le portail client, l'utilisateur clique sur un bouton pour accéder aux informations de sa requête de support.
• (2) Comme l'utilisateur s'est déjà connecté, le client a un jeton valide du fournisseur d'identité.
• (3) L'application cliente envoie une requête POST au point de terminaison Salesforce /services/oauth2/token. Cette requête inclut plusieurs paramètres, qui dépendent de votre cas d'utilisation. Il doit au minimum inclure les paramètres ci-dessous.
  • Un paramètre grant_type, qui indique à Salesforce que cette application souhaite utiliser le flux d'échange de jetons.
  • Un paramètre de subject_token avec le jeton du fournisseur d'identité.
  • Un paramètre subject_token_type, qui indique le type de jeton, par exemple un jeton d'accès opaque, un jeton d'actualisation, un jeton d'identification, une assertion SAML ou un jeton Web JSON (JWT).
  • Une client_id qui indique à Salesforce quelle application cliente externe est enregistrée pour ce client.
• (4) L'exécution OAuth Salesforce reçoit la requête POST et la valide. Si la requête est valide, Salesforce transmet le jeton du fournisseur d'identité à un gestionnaire d'échange de jetons Apex.
• (5) Le gestionnaire d'échange de jetons Apex valide le jeton. Dans le cadre de sa validation, le gestionnaire peut interpeller le fournisseur d'identité.
  

  Remarque Cet appel au fournisseur d'identité est facultatif et dépend du développement de votre gestionnaire. Si vous n'incluez pas cet appel externe, le flux passe à l'étape 7.
• (6) (Facultatif) S'il est appelé, le fournisseur d'identité renvoie des informations pour aider le gestionnaire à valider le jeton.
• (7) Le gestionnaire mappe l'objet du jeton avec un objet Salesforce. Pour obtenir plus d'informations sur le sujet, le gestionnaire peut de nouveau appeler le fournisseur d'identité.
  

  Remarque Ce deuxième appel au fournisseur d'identité est également facultatif. Si vous n'incluez pas cet appel externe, le flux passe à l'étape 9.
• (8) (Facultatif) S'il est appelé, le fournisseur d'identité renvoie les informations utilisateur au gestionnaire d'échange de jetons.
• (9) Si le gestionnaire trouve un utilisateur Salesforce existant, il renvoie un utilisateur. S'il ne trouve pas d'utilisateur existant, il configure un nouvel objet Utilisateur et le renvoie à Salesforce pour insertion automatisée.
• (10) L'exécution OAuth de Salesforce vérifie si le gestionnaire a renvoyé un utilisateur existant. Sinon, Salesforce insère un nouvel utilisateur au nom du gestionnaire d'échange de jetons.
• (11) L'exécution OAuth de Salesforce renvoie un jeton d'accès au client. La réponse de jeton inclut également tous les autres jetons et paramètres demandés, tels qu'un jeton d'actualisation ou un jeton d'identification.
• (12) Le client reçoit la réponse de jeton avec le jeton d'accès et les autres jetons demandés.
• (13) (Facultatif) Si nécessaire, le client peut appeler le point de terminaison des informations utilisateur Salesforce pour obtenir plus d'informations sur l'utilisateur et se connecter.
• (14) Le client peut désormais utiliser le jeton d'accès pour soumettre une requête authentifiée à un point de terminaison Salesforce protégé.
• (15) Salesforce accorde l'accès aux ressources demandées.

À la fin du flux, l'utilisateur peut se connecter via le fournisseur d'identité et accéder à ses données Salesforce dans l'application cliente, sans jamais se connecter directement à Salesforce. Ils peuvent par exemple se connecter via Okta et accéder aux informations de leur requête de support, fournies par Salesforce, dans votre portail client.