> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Apprenez à tester le flux XAA de bout en bout.
# Tester le flux Cross App Access (XAA)
export const ReleaseStageNotice = ({feature, stage, plans, contact, terms}) => {
const stageTextMap = {
"beta": "Bêta",
"ea": "Accès anticipé"
};
const stageText = stageTextMap[stage] || "une étape du cycle de publication";
const prsLink = "/docs/troubleshoot/product-lifecycle/product-release-stages";
const linkify = (text, url) => {
return {text};
};
const includeDetails = (plans, contact, terms) => {
const hasDetails = terms || plans || contact;
if (!hasDetails) return null;
return
{plans && <>Cette fonctionnalité est offerte avec les {linkify(`${plans} forfaits`, "https://auth0.com/pricing")}. }
{contact && "Pour y participer, communiquez avec " + contact + ". "}
{terms && <>En utilisant cette fonctionnalité, vous acceptez les conditions applicables de l’essai gratuit énoncées dans le {linkify("Master Subscription Agreement", "https://www.okta.com/legal")} d’Okta.}
;
};
return
La fonctionnalité {feature} est en {linkify(stageText, prsLink)}.
{includeDetails(plans, contact, terms)}
;
};
Pour tester le flux XAA de bout en bout, vous devez vérifier que votre locataire Auth0 peut accepter les requêtes JWT-Bearer envoyées par l’application demandeuse. Auth0 le prend en charge par défaut.
Avant de pouvoir tester le flux XAA de bout en bout, assurez-vous de faire ce qui suit :
* Mettez à jour le champ **URI de redirection** avec l’URL de rappel de votre application de test, qui agit comme application demandeuse dans votre locataire Okta, comme expliqué dans [Enregistrer l’application demandeuse dans Okta](/fr-CA/docs/secure/call-apis-on-users-behalf/xaa/set-up-xaa-test-environment#register-the-requesting-app-in-okta).
* Fournissez à votre représentant Okta les renseignements suivants :
* L’URL d’émetteur de votre locataire Auth0. Votre application de ressource est associée à l’URL d’émetteur dans l’Okta Integration Network (OIN), ce qui permet aux applications demandeuses de s’y reporter lorsqu’elles demandent des ID-JAG.
* Le `client_id` Auth0 correspondant à chaque application demandeuse dans l’OIN.
Pour obtenir l’URL d’émetteur et l’ID client dans votre locataire Auth0, accédez à **Applications**, sélectionnez votre application, puis sélectionnez **Settings** :
| **Champ** | **Instructions** | **Exemple** |
| -------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| URL d’émetteur | Copiez votre domaine Auth0, ajoutez le préfixe `https://`, puis une barre oblique finale. | `https://tenant.region.auth0.com/` ou, si vos clients utilisent un domaine personnalisé, `https://custom-domain.com/`. |
| `client_id` | Copiez l’ID client de l’application. | `ovBLQycaVq6I0Xyuhq84pwDVyJeXWLyx` |
### Échangez le jeton d’identité contre un ID-JAG
Vous devez d’abord vous connecter à votre application demandeuse en utilisant votre locataire de test Okta. Une fois la connexion réussie et le consentement accordé, Okta redirige le navigateur vers votre application demandeuse avec un code d’autorisation. Votre application demandeuse échange ensuite de façon sécurisée le code d’autorisation contre un jeton d’accès Okta et un jeton d’identité.
Pour échanger le jeton d’identité Okta contre un ID-JAG, l’application demandeuse envoie une [demande d’échange de jeton](https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-token-exchange) au point de terminaison `/token` de votre locataire de test Okta avec les paramètres suivants :
```
POST /oauth2/v1/token HTTP/1.1
Host: {{YOUR_TENANT}}.okta.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience={{YOUR_AUTH0_TENANT_ISSUER_URL}}
&resource={{YOUR_AUTH0_TENANT_API_AUDIENCE}}
&subject_token={{OKTA_ID_TOKEN}}
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_id={{REQUESTING_APP_CLIENT_ID_IN_OKTA}}
&client_secret={{REQUESTING_APP_CLIENT_SECRET_IN_OKTA}}
```
| **Paramètre** | **Description** |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `grant_type` | Le type d’octroi. Définissez-le sur le type d’octroi d’échange de jeton : `urn:ietf:params:oauth:grant-type:token-exchange`. |
| `requested_token_type` | Le type de jeton que l’application veut recevoir en retour du serveur d’autorisation. Définissez-le sur Identity Assertion Authorization Grant, ou ID-JAG : `urn:ietf:params:oauth:token-type:id-jag`. |
| `audience` | Le destinataire visé du jeton final. Définissez-le sur l’URL de l’émetteur de votre locataire Auth0, ou sur votre application de ressource dont le serveur d’autorisation se trouve à cette URL précise. |
| `resource` | Facultatif. L’API de l’application de ressource à laquelle l’application veut accéder. Lorsque le serveur d’autorisation émet le jeton d’accès final, il inclut cette ressource dans la revendication `aud` du jeton, que l’API de l’application de ressource utilisera pour la valider. Si vous ne précisez pas de paramètre `resource`, l’audience par défaut que vous avez définie pour votre locataire est utilisée dans la requête suivante pour obtenir un jeton d’accès. Si vous précisez une valeur `resource` qui ne correspond pas à une audience d’API valide dans votre locataire Auth0, la requête d’échange de jeton n’échoue pas et vous recevez quand même un ID-JAG en retour. Toutefois, la requête suivante visant à obtenir un jeton d’accès avec l’ID-JAG sera rejetée par votre locataire Auth0. |
| `subject_token` | Le jeton que l’application échange. Pour XAA, le jeton de sujet est la « preuve » ou l’« assertion » de l’identité de l’utilisateur. Définissez-le sur le jeton d’identité Okta que l’IdP utilisera pour vérifier l’identité de l’utilisateur. |
| `subject_token_type` | Le type de jeton fourni dans le paramètre `subject_token`. Pour XAA, il précise qu’un jeton d’identité est présenté au serveur d’autorisation. |
| `client_id` | L’ID client de l’application demandeuse au sein de l’IdP d’entreprise qui effectue la requête d’échange de jeton. |
| `client_secret` | Le secret client que cette application demandeuse utilise pour s’authentifier auprès de l’IdP d’entreprise. |
La bêta de XAA ne prend pas en charge la transmission de scopes au point de terminaison `/token` d’Okta. Vous pouvez définir les scopes dans la requête suivante au point de terminaison /token d’Auth0, une fois que l’application demandeuse a reçu l’ID-JAG.
Dans un environnement de production, l’application demandeuse envoie la requête d’échange de jeton au point de terminaison `/token` du locataire Okta de votre client.
### Envoyez l’ID-JAG au point de terminaison `/token` d’Auth0
Une fois que l’application demandeuse reçoit un ID-JAG, elle envoie une [demande de jeton d’accès](https://www.ietf.org/archive/id/draft-parecki-oauth-identity-assertion-authz-grant-05.html#name-access-token-request) au point de terminaison `/token` de votre locataire Auth0 :
```
POST https://{{YOUR_AUTH0_TENANT_DOMAIN}}/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id={{REQUESTING_APP_CLIENT_ID_IN_AUTH0}}
&client_secret={{REQUESTING_APP_CLIENT_SECRET_IN_AUTH0}}
&scope=scope1%20scope2%20
&assertion={{ID_JAG}}
```
| **Paramètre** | **Description** |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `grant_type` | Le type d’octroi. Il indique au serveur d’autorisation qu’il doit s’attendre à recevoir un JSON Web Token (JWT) comme justificatif principal dans la requête. |
| `client_id` | L’ID client de l’application demandeuse dans le serveur d’autorisation de l’application ressource qui effectue l’appel d’API. |
| `client_secret` | Le secret client de l’application demandeuse dans le serveur d’autorisation de l’application ressource qui effectue l’appel d’API. |
| `scope` | L’ensemble des permissions que l’application demandeuse demande pour le jeton d’accès. |
| `assertion` | L’ID-JAG ou le JSON Web Token (JWT) qui sert de porteur de l’assertion d’identité. |
Après que le serveur d’autorisation Auth0 a validé l’ID-JAG pour vérifier l’identité de l’utilisateur, il émet un jeton d’accès pour appeler l’audience d’API cible de votre locataire Auth0. Le jeton d’accès comprend aussi les scopes que vous avez demandés et qui sont autorisés par le RBAC et les autres politiques définies dans votre locataire Auth0.
Le serveur d’autorisation Auth0 n’émet pas de jetons d’actualisation en réponse aux échanges de jetons ID-JAG. Par conséquent, l’application demandeuse doit obtenir un nouvel ID-JAG auprès de l’IdP d’entreprise et se soumettre aux contrôles d’accès applicables pour obtenir un nouveau jeton d’accès au moyen de XAA.