API Identité headless : Flux Connexion sans mot de passe headless pour des clients publics
Facilitez la connexion des utilisateurs clients et partenaires à une application hors plate-forme avec le flux Connexion sans mot de passe headless. Ce flux permet aux utilisateurs de se connecter à votre application en saisissant leur adresse e-mail ou leur numéro de téléphone, et de confirmer leur identité avec un mot de passe à usage unique (OTP). Vous contrôlez l’expérience frontale dans votre application. Dans le back-end, votre application appelle l'API Connexion sans mot de passe headless via un site Experience Cloud pour connecter l'utilisateur. Ces étapes montrent le fonctionnement du flux avec un client public, notamment une application à page unique, qui ne peut pas garder les informations privées.
Éditions requises
| Disponible avec : Salesforce Classic (pas disponible dans toutes les organisations) et Lightning Experience |
| Disponible avec : Enterprise Edition, Unlimited Edition et Developer Edition |
Ce flux est une variante du flux Code d'autorisation et identifiants, qui étend le type d'octroi Code d'autorisation OAuth 2.0. De la même façon que les autres variantes, elle inclut les appels aux points de terminaison Salesforce pour obtenir un code d'autorisation et l'échanger contre un jeton d'accès. Dans cette variante, votre application échange un identificateur de requête et un mot de passe à usage unique contre le code d'autorisation, au lieu du nom d'utilisateur et du mot de passe dans un flux de connexion headless plus traditionnel. Le code est ensuite échangé contre un jeton d'accès.
Avant de configurer ce flux, procédez comme suit.
- Prérequis à Identité headless
- Intégrez votre application hors plate-forme à Salesforce en utilisant l'une des options ci-dessous.
- Configurez les paramètres Experience Cloud pour Connexion sans mot de passe headless.
Voici un cas d'utilisation de flux Connexion sans mot de passe headless. Vous travaillez pour une agence de voyages qui gère les informations des clients dans Salesforce, et vous avez déjà implémenté la connexion et l'inscription headless dans votre application mobile hors plate-forme. Pendant votre processus d'inscription, vous récupérez l'adresse e-mail de l'utilisateur. Pour faciliter le processus de connexion, vous configurez la connexion sans mot de passe headless avec E-mail comme méthode de vérification. Ainsi, lorsque des utilisateurs visitent votre application, ils peuvent saisir leur adresse e-mail et recevoir un mot de passe à usage unique (OTP). Lorsqu'un utilisateur saisit le mot de passe à usage unique dans votre application, Salesforce vérifie son identité et il est connecté. Il peut accéder aux données Salesforce protégées, par exemple l'historique des voyages.
En option, pour encore plus de flexibilité avec votre expérience utilisateur, vous pouvez utiliser un gestionnaire Apex headless de découverte des utilisateurs pour récupérer des utilisateurs. Développez votre gestionnaire pour référencer les utilisateurs en fonction de leur adresse e-mail, numéro de téléphone ou tout autre identifiant qui peut être lié à un utilisateur Salesforce. Par exemple, invitez les utilisateurs à se connecter avec leur numéro de confirmation de voyage. Lorsque l'utilisateur saisit son numéro de confirmation, Salesforce recherche le nom d'utilisateur associé et envoie un mot de passe à usage unique à l'adresse e-mail de l'utilisateur. Pour plus d'informations sur le développement de votre gestionnaire Apex, consultez Auth.HeadlessUserDiscoveryHandler dans le guide de référence Apex.
Pour un client public qui ne peut pas protéger le secret consommateur de l'application, par exemple une application mobile ou une application à page unique, vous devez prendre en compte quelques considérations de sécurité supplémentaires en élaborant le flux. Lorsque vous configurez vos paramètres de connexion et d'inscription Experience Cloud, vous devez activer au moins l'une des options de sécurité suivantes : Demander l'authentification pour accéder à cette API ou Demander reCAPTCHA pour accéder à cette API. Pour des clients publics, nous recommandons de toujours activer le paramètre Demander reCAPTCHA pour accéder à cette API, avec laquelle votre application doit toujours inclure un jeton reCAPTCHA dans la requête initiale à l'API Connexion sans mot de passe headless. Nous recommandons de ne jamais activer le paramètre Demander l'authentification pour accéder à cette API pour des clients publics. Avec ce paramètre, votre requête doit inclure un jeton d’accès émis pour un utilisateur de l’intégration interne et les clients publics ne peuvent pas garder le jeton accès secret.
Pour renforcer la sécurité de votre flux, nous recommandons de toujours implémenter l'extension Clé de vérification pour l'échange de code (PKCE). Généralement, une application cliente privée utilise le secret consommateur en tant que mot de passe pour accéder en toute sécurité à Salesforce. Cependant, les clients publics ne peuvent pas protéger le secret consommateur, car ils n'ont pas de back-end privé. L'extension PKCE permet de combler cette lacune avec des paramètres que seules votre application et Salesforce peuvent vérifier. Ces paramètres permettent de vérifier que le client initiant le flux est celui qui le complète.
Pour élargir vos options de modèle pour l’e-mail de mot de passe à usage unique (OTP) envoyé aux utilisateurs pendant le flux, abonnez-vous à la liste d'autorisations de modèles d'e-mail et créez une liste d'autorisations contenant des modèles personnalisés. Consultez Utilisation de modèles d'e-mail multiples pour des flux headless.
Voici une vue d’ensemble du flux Connexion sans mot de passe headless pour un client public.
- Un utilisateur ouvre votre application et affiche un formulaire de connexion natif dans votre application. Ils saisit son adresse e-mail ou numéro de téléphone à l'invite du formulaire de connexion (1).
- Si vous n'utilisez pas un gestionnaire de découverte utilisateur headless, votre application recherche le nom d'utilisateur associé au numéro de téléphone ou à l'adresse e-mail de l'utilisateur (2).
- Votre application soumet une requête POST headless à l'API Connexion sans mot de passe headless (point de terminaison
services/auth/headless/init/passwordless/loginde votre site Experience Cloud (3). - (Facultatif) Si vous utilisez un gestionnaire de découverte utilisateur headless, le gestionnaire recherche le nom d'utilisateur associé aux données transmises dans le paramètre
login_hintet vérifie que l'adresse e-mail ou le numéro de téléphone associé à l'utilisateur est vérifié. - Salesforce renvoie un message de réussite à votre application. Il envoie également un identifiant de requête, qui est utilisé plus loin dans le flux (4a).
- Selon la méthode de vérification, Salesforce envoie à l'utilisateur un e-mail ou un SMS contenant un mot de passe à usage unique (4b).
- Votre application affiche en natif un formulaire de vérification du mot de passe à usage unique (5).
- L'utilisateur reçoit son mot de passe à usage unique et le saisit dans votre formulaire de vérification (6).
- Si vous utilisez la PKCE, que nous recommandons vivement, votre application génère les paramètres PKCE (7).
- Votre application démarre le flux Code d'autorisation et identifiants avec une requête POST ou GET au point de terminaison d'autorisation Salesforce (
services/oauth2/authorize). La requête contient l'ID et le mot de passe à usage unique de la requête, ainsi que d’autres paramètres pour identifier l’application et spécifier le type de requête (8). - Salesforce vérifier l'ID et le mot de passe à usage unique de la requête, et renvoie une redirection 302 à une URL préconfigurée, qui contient le code d'autorisation. Si le flux est exécuté dans le navigateur, la redirection 302 est traitée dans le navigateur et la réponse est livrée au point de terminaison de rappel (9).
- Un point de terminaison de rappel extrait le code d'autorisation et le renvoie à votre application (10).
- Votre application reçoit le code d'autorisation et initie un échange de code en l'envoyant avec d'autres paramètres dans une requête POST au point de terminaison de jeton Salesforce (
services/oauth2/token) (11). - Salesforce valide la requête de jeton, et renvoie le jeton d'accès et l'état (12).
- Votre application traite la réponse du jeton d'accès et crée la session de l'utilisateur (13).
- L'utilisateur est maintenant connecté et exécute dans votre application une action qui nécessite l'accès aux données Salesforce, par exemple cliquer sur un bouton pour afficher l'historique des commandes (14).
- Votre application envoie une requête authentifiée à une API Salesforce protégée (15).
- L'utilisateur peut maintenant accéder à ses données Salesforce dans votre application hors plate-forme (16).
Comme indiqué à l'étape 10, ce flux nécessite un point de terminaison de rappel pouvant gérer la redirection 302, et renvoyer le code d'autorisation et d'autres paramètres à votre application. Pour les implémentations dans lesquelles vous effectuez l'échange de code dans votre navigateur, vous pouvez utiliser le point de terminaison Salesforce /services/oauth2/echo. Ce point de terminaison analyse automatiquement la redirection 302, extrait les paramètres, puis les renvoie à votre application sous le format JSON. Nous utilisons le point de terminaison echo dans les exemples de code de ce flux.
Saisie de l'adresse e-mail ou du numéro de téléphone par l'utilisateur pour la connexion
Le flux démarre lorsqu'un utilisateur visite votre application. Votre application affiche en natif un formulaire de connexion qui demande uniquement l’adresse e-mail ou le numéro de téléphone de l’utilisateur. Alternativement, si vous utilisez un gestionnaire de découverte utilisateur headless qui référence les utilisateurs en fonction d'un identifiant différent, par exemple un numéro de commande, votre application peut afficher un formulaire de connexion invitant l'utilisateur à saisir l'identifiant. L'utilisateur saisit ses informations, puis clique sur un bouton de connexion.
Recherche du nom d'utilisateur par votre application
Si vous n'utilisez pas un gestionnaire de découverte utilisateur headless, votre application recherche l'adresse e-mail ou le numéro de téléphone de l'utilisateur et trouve le nom d'utilisateur associé.
Si vous utilisez un gestionnaire de découverte utilisateur headless, votre application ignore cette étape. Votre gestionnaire référence l'utilisateur après avoir soumis la requête initiale.
Envoi d'une requête à l'API Connexion headless par votre application
Depuis le navigateur, votre application soumet une requête POST headless à l'API Connexion sans mot de passe headless (le point de terminaison services/auth/headless/init/passwordless/login de votre site Experience Cloud.
Insérez les paramètres ci-dessous dans le corps de la requête.
| Paramètre | Obligatoire ? | Description |
|---|---|---|
verificationmethod
|
Oui. | La méthode que vous souhaitez utiliser pour vérifier l'identité de l’utilisateur. Vous pouvez utiliser email ou sms. |
username
|
Obligatoire si vous n'utilisez pas un gestionnaire de découverte utilisateur headless. | Le nom d'utilisateur lié à l'adresse e-mail ou au numéro de téléphone que l'utilisateur a soumis. |
recaptcha
|
Obligatoire si les conditions suivantes s'appliquent à vous :
|
Un jeton crypté émis par l'API Google reCAPTCHA lorsqu'un passe un défi reCAPTCHA |
recaptchaevent
|
Obligatoire si les conditions suivantes s'appliquent à vous :
|
Un objet JSON contenant les sous-paramètres ci-dessous.
Pour plus d'informations, consultez la documentation reCAPTCHA de Google. |
emailtemplate
|
Requis pour spécifier plusieurs modèles d'e-mail personnalisés si la liste d'autorisations de modèles d'e-mail est activée. Si vous n'avez pas activé la liste d'autorisations de modèles d'e-mail, vous ne pouvez pas inclure ce paramètre. Si vous n'incluez pas ce paramètre, Salesforce utilise le modèle d'e-mail par défaut configuré dans vos paramètres Experience Cloud, que la liste d'autorisations soit activée ou non. Si aucun modèle n'est configuré, Salesforce utilise un modèle d'e-mail Mot de passe à usage unique par défaut. La langue du modèle d'e-mail pour les modèles par défaut est contrôlée par les paramètres linguistiques de l'utilisateur dans Salesforce. |
Le nom du développeur du modèle d'e-mail personnalisé. Ce paramètre peut inclure uniquement un modèle d'e-mail répertorié dans la liste d'autorisations. Pour contrôler la langue des modèles d'e-mail personnalisés, créez des modèles dans la langue de votre choix. |
login_hint
|
Obligatoire si vous utilisez un gestionnaire Apex headless de découverte d'utilisateurs. | Un identifiant que votre gestionnaire Apex peut utiliser pour retrouver le compte Salesforce d'un utilisateur. Par exemple, récupérez le numéro de commande d'un utilisateur dans votre application et transmettez-le dans le paramètre login_hint. Nous envoyons la valeur login_hint directement à votre gestionnaire Apex. |
Voici un exemple de requête à l'API Connexion sans mot de passe headless. Cette requête concerne une implémentation qui n'utilise pas de gestionnaire de découverte utilisateur headless.
POST /services/auth/headless/init/passwordless/login? HTTP 1.1
Host: MyExperienceCloudSite.my.site.com
{
"verificationmethod": "email",
"username": "janice.edwards@example.com",
"recaptcha": "***********",
"emailtemplate": "unfiled$public/SalesNewCustomerEmail"
}Voici un exemple de requête si vous utilisez un gestionnaire de découverte utilisateur headless.
POST /services/auth/headless/init/passwordless/login? HTTP 1.1
Host: MyExperienceCloudSite.my.site.com
{
"verificationmethod": "email",
"login_hint": "<user identifier such as email address, phone number, order number>",
"recaptcha": "***********",
"emailtemplate": "unfiled$public/SalesNewCustomerEmail"
}(Facultatif) Le Gestionnaire de découverte des utilisateurs headless recherche un utilisateur
Si vous utilisez un gestionnaire de découverte utilisateur headless, le gestionnaire prend le paramètre login_hint et recherche l'utilisateur associé. Le gestionnaire confirme que l'adresse e-mail ou le numéro de téléphone de l'utilisateur est vérifié.
Pour un exemple de gestionnaire, consultez Auth.HeadlessUserDiscoveryHandler.
Renvoi d'un message de réussite à votre application par Salesforce
Si la requête réussit, Salesforce renvoie un message de réussite qui contient un identifier pour la requête, qui est important plus loin dans le flux lors de l'échange d'un jeton d'accès. Voici un exemple de message de réussite :
{
"status”: "success",
"email": "jedwards@example.com",
"identifier": “0RXXXXXXXX”
}Envoi d'un mot de passe à l'utilisateur par Salesforce
Immédiatement après avoir envoyé l'identifiant de la requête à votre application, Salesforce envoie également à l'utilisateur un e-mail ou un SMS contenant le mot de passe à usage unique (OTP).
Affichage d'un formulaire de vérification par votre application
Dans votre application, vous affichez nativement un formulaire de vérification dans lequel l'utilisateur peut saisir son mot de passe à usage unique.
Saisie du mot de passe à usage unique par l'utilisateur
L'utilisateur reçoit le mot de passe à usage unique par e-mail ou SMS, puis le saisit dans votre formulaire de vérification de votre application.
Génération des paramètres de PKCE par votre application
Si vous utilisez l'extension PKCE, que nous recommandons vivement, votre application génère les paramètres code_verifier et code_challenge.
La spécification PKCE définie dans RFC 7636 inclut également un paramètre facultatif code_challenge_method que vous pouvez envoyer dans la requête d'autorisation. Salesforce ignore toute valeur que vous envoyez dans ce paramètre et applique par défaut SHA256.
Envoi d'une requête au point de terminaison d'autorisation par votre application
Dès que l'utilisateur vérifie son identité en saisissant le mot de passe à usage unique, votre application initialise le flux Code d'autorisation et identifiants avec une requête au point de terminaison d'autorisation, qui échange l'ID de la requête et le mot de passe à usage unique contre un code d'autorisation.
Insérez ces en-têtes dans la requête d'autorisation.
| En-tête | Obligatoire ? | Description |
|---|---|---|
Auth-Request-Type
|
Oui. | Spécifie le type de requête que vous souhaitez envoyer à Salesforce. Pour la connexion sans mot de passe headless, cette valeur doit être définie sur passwordless-login. |
Auth-Verification-Type
|
Oui. | La méthode utilisée pour vérifier l'identité de l’utilisateur. Salesforce prend en charge deux valeurs pour la méthode de vérification : email et sms. |
Authorization
|
Oui. | Un en-tête de base qui identifie la requête de connexion sans mot de passe que Salesforce peut lier aux informations stockées de l'utilisateur. Incluez l'identifiant de la requête ( |
Uvid-Hint
|
Non. Si vous implémentez le flux utilisateur invité dans votre application, vous pouvez également utiliser cet en-tête pour transmettre dans un jeton d'accès basé sur JWT contenant un ID de visiteur unique (UVID) lié à l'identité d'un utilisateur invité. En transmettant l’UVID dans un flux utilisateur nommé, vous pouvez transmettre des informations contextuelles à une session utilisateur nommé depuis une session utilisateur invité, par exemple les préférences de cookie de l’utilisateur. Au lieu de transmettre un jeton basé sur JWT avec UVID dans un en-tête, vous pouvez également transmettre la valeur UVID brute dans le corps de la requête. |
Un jeton d'accès est basé sur JWT contenant une valeur UVID brute, qui est un UUID version 4 entièrement généré et géré par votre application. Pour obtenir un jeton d’accès avec un UVID, vous devez activer l’émission de jetons d’accès basés sur JWT par votre application cliente externe ou connectée et implémenter le flux invité headless dans votre application. |
Insérez les paramètres ci-dessous dans le corps de la requête.
| Paramètre | Obligatoire ? | Description |
|---|---|---|
response_type
|
Oui. | Le type d'octroi OAuth 2.0 que demande votre application. Comme ce flux est une variante du flux Code d'autorisation et identifiants, cette valeur doit être code_credentials. |
client_id
|
Oui. | La clé consommateur de l'application cliente externe ou de l'application connectée. |
redirect_uri
|
Oui. | L'URL vers laquelle les utilisateurs sont redirigés après la réussite de l'authentification. Pour ce flux, vous pouvez utiliser le point de terminaison echo, |
code_challenge
|
Uniquement si vous utilisez PKCE. L'extension PKCE est vivement recommandée, en particulier pour les clients publics. | Spécifie la valeur de hachage SHA256 de la valeur Si Si |
uvid_hint
|
Non. Si vous implémentez le flux utilisateur invité dans votre application, vous pouvez également utiliser ce paramètre pour transmettre une valeur UVID liée à l'identité d'un utilisateur invité, en transmettant les informations contextuelles d'une session utilisateur invité à une session utilisateur nommé. Au lieu de transmettre l’UVID dans le corps de la requête, vous pouvez également le transmettre dans un jeton basé sur JWT avec un UVID via l’en-tête |
Une valeur UVID brute, qui est un UUID version 4 entièrement généré et géré par votre application. Pour obtenir un UVID, vous devez activer l’émission de jetons d’accès basés sur JWT par votre application cliente externe ou connectée et implémenter le flux invité headless dans votre application. |
Voici un exemple de requête de point de terminaison d'autorisation : Cet exemple inclut PKCE.
POST /services/oauth2/authorize? HTTP 1.1
Host: MyExperienceCloudSite.my.site.com
Auth-Request-Type: passwordless-login
Auth-Verification-Type: email
Authorization: Basic <base64-encoded identifier:OTP
response_type=code_credentials&
client_id=***********&
redirect_uri=https://www.MyExperienceCloudSite.my.site.com/services/oauth2/echo&
code_challenge=********
Vérification de la requête et renvoi d'une redirection 302 par Salesforce
Lorsque la requête atteigne le point de terminaison d'autorisation, Salesforce vérifie l'identificateur de la requête et le mot de passe à usage unique. Salesforce renvoie ensuite une redirection HTTP 302 vers une URL préconfigurée contenant le code d'autorisation. Si le flux se produit dans le navigateur, la redirection 302 est traitée dans le navigateur et Salesforce envoie automatiquement la réponse de redirection à l'URL de redirection, qui est le point de terminaison de rappel. Voici un exemple d'URL préconfigurée.
https://www.MyDomainName.my.site.com/services/apexrest/code/exchange?code=aPrxC1*******
&sfdc_community_url=https%3A%2F%2FMyDomainName.my.site.com&sfdc_community_id=0DBxxxxxxxxxxxxEnvoi du code d'autorisation à votre application par le point de terminaison de rappel
Le point de terminaison de rappel extrait le code d'autorisation et le renvoie à votre application. Dans ces exemples de code, l'URL de redirection pointe vers le point de terminaison de rappel /services/oauth2/echo dans le site Experience Cloud. Ce point de terminaison analyse automatiquement la redirection 302, extrait le code d'autorisation et d'autres paramètres et les renvoie à votre application sous le format JSON.
L’application initie l'échange de jetons
L'application reçoit la réponse du code. Pour obtenir un jeton d'accès, l'application initie l'échange de code avec une requête POST headless au point de terminaison /services/oauth2/token.
Cette requête n'a aucun en-tête. Insérez les paramètres ci-dessous dans le corps de la requête.
| Paramètre | Obligatoire ? | Description |
|---|---|---|
code
|
Oui. | Le serveur d'autorisation crée un code d'autorisation, un jeton éphémère, et le transmet au client une fois l'authentification réussie. Le client envoie le code d'autorisation au serveur d'autorisation pour obtenir le jeton d'accès et éventuellement un jeton d'actualisation. |
client_id
|
Oui. | La clé consommateur de l'application cliente externe ou de l'application connectée. |
redirect_uri
|
Oui. | L'URL vers laquelle les utilisateurs sont redirigés après une authentification réussie. L'URI de redirection doit correspondre à l'une des valeurs du champ URL de rappel de l'application connectée. Sinon, l'approbation échoue. Cette valeur doit être codée en URL. Pour ce flux, vous pouvez utiliser le point de terminaison echo, |
grant_type
|
Oui. | Le type de validation que l'application peut fournir pour prouver qu'elle est un visiteur de confiance. Pour le flux Code d'autorisation et identifiants, la valeur doit être authorization_code. |
code_verifier
|
Uniquement si vous utilisez PKCE. | Spécifie 128 octets de données aléatoires avec une entropie élevée pour rendre la valeur du code difficile à deviner. Définissez ce paramètre pour empêcher les attaques par interception de code d'autorisation. La valeur doit être codée en base64url comme défini dans https://datatracker.ietf.org/doc/html/rfc4648#section-5. Si une valeur Si la valeur de |
Voici un exemple de requête de jeton : Cet exemple utilise l'extension PKCE.
POST services/oauth2/token? HTTP 1.1
Host: MyExperienceCloudSite.my.site.com
code=********&
client_id=**********&
redirect_uri=https://MyExperienceCloudSite.my.site.com/services/oauth2/echo&
grant_type=authorization_code&
code_verifier=*******Salesforce accorde un jeton accès
Après la validation des identifiants de l'application. Salesforce renvoie un jeton d'accès au navigateur. Voici un exemple de réponse de jeton d'accès sous le format JSON.
{
"access_token":"*******************",
"sfdc_community_url":"https://MyDomainName.my.site.com",
"sfdc_community_id":"0DBxxxxxxxxxxxx",
"signature":"ts6wm/svX3jXlCGR4uu+SbA04M6qhD1SAgVTEwZ59P4=",
"scope":"openid api",
"id_token":"XXXXXX",
"instance_url":"https://yourInstance.salesforce.com",
"id":"https://yourInstance.salesforce.com/id/00Dxxxxxxxxxxxx/005xxxxxxxxxxxx",
"token_type":"Bearer",
"issued_at":"1667600739962"
}La réponse de jeton d'accès contient les paramètres ci-dessous.
| Paramètre | Obligatoire ? | Description |
|---|---|---|
access_token
|
Oui. | Le jeton OAuth utilisé par une application cliente externe ou connectée pour demander l'accès à une ressource protégée au nom de l'application cliente. Des autorisations supplémentaires sous forme d'étendues peuvent accompagner le jeton d'accès. |
id
|
Oui. | Une URL d'identité qui peut être utilisée pour identifier l'utilisateur et pour demander plus d'informations sur l'utilisateur. Consultez URL d'identité. |
id_token
|
Non. | Une structure de données signée qui contient les attributs de l'utilisateur authentifié, notamment l'identifiant unique de l'utilisateur et la date d'émission du jeton. Il identifie également l'application demandeur. Consultez Spécifications OpenID Connect. |
instance_url
|
Oui. | Une URL indiquant l'instance de l'organisation de l'utilisateur. Par exemple, https://yourInstance.salesforce.com/. |
issued_at
|
Oui. | Un horodatage indiquant quand la signature a été créée, exprimé en nombre de millisecondes depuis 1970-01-01T0:0:0Z UTC. |
refresh_token
|
Non. | Le jeton obtenu du flux de jetons serveur Web, utilisateur-agent ou application hybride. Cette valeur est un secret. Prenez les mesures appropriées pour la protéger. Ce paramètre est renvoyé uniquement si votre application cliente externe ou votre application connectée est configurée avec une étendue refresh_token. |
signature
|
Oui. | La signature HMAC-SHA256 codée en Base64 signée par le client_secret. La signature peut inclure l'ID et la valeur issued_at concaténés, que vous pouvez utiliser afin de vérifier si l'URL d'identité a changé depuis que le serveur l'a envoyée. |
sfdc_community_url
|
Oui. | L'URL du site Experience Cloud. |
sfdc_community_id
|
Oui. | L'ID de site Experience Cloud de l'utilisateur. |
state
|
Non. | L'état demandé par le client. Cette valeur est incluse uniquement si le paramètre state figure dans la chaîne de requête d'origine. |
token_type
|
Oui. | Un type de jeton Bearer, utilisé pour toutes les réponses qui incluent un jeton d'accès. |
Création de la session de l'utilisateur par l'application
Le navigateur reçoit les informations de la réponse de jeton et crée la session utilisateur. Votre application appelle le point de terminaison Salesforce User Info pour confirmer la réussite de la connexion.
Connexion de l'utilisateur et exécution d'une action dans l'application
L'utilisateur est maintenant connecté. Dans votre application, il exécute une action qui nécessite l'accès aux données Salesforce. Il clique par exemple sur un bouton pour afficher l'historique de ses commandes, qui est stocké dans Salesforce.
L'application effectue un appel authentifié à un point de terminaison Salesforce
Pour accéder aux données Salesforce de l’utilisateur, votre application utilise le jeton d’accès pour faire un appel authentifié à un point de terminaison Salesforce protégé, tel qu’une API Salesforce.
L'utilisateur peut accéder aux données Salesforce
Le client peut maintenant accéder aux données Salesforce protégées dans votre application. Il peut par exemple consulter l'historique de ses commandes. Du point de vue de l'utilisateur, le processus complet depuis la connexion jusqu'à l'accès aux données a été effectué sans quitter l'application.
