Tester le flux Cross App Access (XAA)

Apprenez à tester le flux XAA de bout en bout.

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.
• 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 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 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.