Passer au contenu principal
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 :
FieldInstructionsExample
Issuer URLCopiez 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_idCopiez 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}}
ParameterDescription
grant_typeLe type de grant. Définissez-le au type de grant d’échange de jeton : urn:ietf:params:oauth:grant-type:token-exchange.
requested_token_typeLe 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.
audienceLe 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.
resourceFacultatif. 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_tokenLe 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_typeLe 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_idL’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_secretLe 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ètreDescription
grant_typeLe 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_idL’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_secretLe Secret client de l’application requérante au sein du Serveur d’autorisation de l’application de ressource qui effectue l’appel d’API.
scopeL’ensemble des permissions que l’application requérante demande pour le jeton d’accès.
assertionL’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.