Tester le flux Cross App Access (XAA)

Cross App Access (XAA) est actuellement en version bêta. En utilisant cette fonctionnalité, vous acceptez les conditions applicables de la période d’essai gratuite figurant dans le contrat de souscription principal d’Okta. Pour en savoir plus sur le cycle de publication des produits Auth0, consultez Étapes de publication des produits. Pour participer à ce programme, communiquez avec l’assistance Auth0 ou votre gestionnaire de compte technique.

Pour tester le flux XAA de bout en bout, vous devez vérifier que votre tenant Auth0 peut accepter les requêtes JWT de type Bearer envoyées par l’application demandeuse (Requesting App). Auth0 gère cela pour vous nativement. Avant de pouvoir tester le flux XAA de bout en bout, assurez-vous de :

Mettre à jour le champ Redirect URI pour qu’il pointe vers l’URL de rappel de votre application de test qui agit comme application demandeuse dans votre tenant Okta, comme expliqué dans Enregistrer l’application demandeuse dans Okta.
Fournir à votre représentant Okta les informations suivantes :
- L’URL de l’émetteur (issuer URL) de votre tenant Auth0. Votre Resource App est associée à l’URL de l’émetteur dans l’Okta Integration Network (OIN), ce qui permet aux applications demandeuses de s’y référer lorsqu’elles demandent des ID-JAG.
- Le client_id Auth0 qui correspond à chaque application demandeuse dans l’OIN.

Pour obtenir l’URL de l’émetteur et l’ID client dans votre tenant Auth0, accédez à Applications, sélectionnez votre application, puis sélectionnez Settings :

Field	Instructions	Example
Issuer URL	Copiez votre domaine Auth0, préfixez-le avec `https://`, puis ajoutez 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`

Échanger le jeton ID contre un ID-JAG

Tout d’abord, vous devez ouvrir une session dans votre Requesting App avec votre tenant de test Okta. Lorsque vous ouvrez une session avec succès et accordez votre consentement, Okta redirige le navigateur vers votre Requesting App avec un code d’autorisation. Votre Requesting App échange ensuite de façon sécurisée le code d’autorisation contre un jeton d’accès Okta et un jeton ID. Pour échanger le jeton ID Okta contre un ID-JAG, la Requesting App effectue une requête d’échange de jeton au point de terminaison /token de votre tenant 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}}

Parameter	Description
`grant_type`	Le type de grant. Définissez-le au type de grant d’échange de jeton : `urn:ietf:params:oauth:grant-type:token-exchange`.
`requested_token_type`	Le type de jeton que le client veut recevoir 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 prévu du jeton final. Indiquez l’URL d’émetteur (issuer) de votre tenant Auth0, ou votre application de ressource (Resource App) dont le serveur d’autorisation se trouve à cette URL précise.
`resource`	Facultatif. L’API de l’application de ressource (Resource App) à laquelle le client 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 validation. Si vous ne précisez pas de paramètre `resource`, l’audience par défaut que vous avez définie pour votre tenant est utilisée dans la prochaine requête visant à obtenir un jeton d’accès. Si vous indiquez une `resource` qui ne correspond pas à une audience d’API valide dans votre tenant 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 tenant Auth0.
`subject_token`	Le jeton que le client échange. Pour XAA, le jeton sujet est la « preuve » ou « assertion » de l’identité de l’utilisateur. Définissez-le sur le jeton ID 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 ID est présenté au serveur d’autorisation.
`client_id`	L’ID client de l’application demandeuse (Requesting App) 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 (Requesting App) utilise pour s’authentifier auprès de l’IdP d’entreprise.

La version 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 prochaine requête 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 effectue la requête d’échange de jeton au point de terminaison /token du tenant Okta de votre client.

Envoyer l’ID-JAG au point de terminaison /token d’Auth0

Une fois que l’application requérante obtient un ID-JAG, elle envoie une requête de jeton d’accès au point de terminaison /token de votre tenant 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 (grant). Il indique au Serveur d’autorisation qu’il doit s’attendre à recevoir un JSON Web Token (JWT) comme information d’identification principale dans la requête.
`client_id`	L’ID client de l’application requérante au sein du Serveur d’autorisation de l’application de ressource qui effectue l’appel d’API.
`client_secret`	Le Secret client de l’application requérante au sein du Serveur d’autorisation de l’application de ressource qui effectue l’appel d’API.
`scope`	L’ensemble des permissions que l’application requérante demande pour le jeton d’accès.
`assertion`	L’ID-JAG ou le JSON Web Token (JWT) qui fait office de porteur de l’assertion d’identité.

Une fois 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 destiné à l’audience API cible de votre tenant Auth0. Le jeton d’accès inclut également les scopes que vous avez demandés et qui sont autorisés par le RBAC et les autres politiques définies dans votre tenant 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 requérante 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 via XAA.

Protégez votre Application

Appeler des API au nom de l’utilisateur

Protéger votre tenant

Conformité

Tester le flux Cross App Access (XAA)

Échanger le jeton ID contre un ID-JAG

Envoyer l’ID-JAG au point de terminaison /token d’Auth0

​Échanger le jeton ID contre un ID-JAG

​Envoyer l’ID-JAG au point de terminaison /token d’Auth0

Échanger le jeton ID contre un ID-JAG

Envoyer l’ID-JAG au point de terminaison /token d’Auth0