Tests de bout en bout

Pour tester le flux XAA, l’application demandeuse doit obtenir un grant d’autorisation d’assertion d’identité (ID-JAG) auprès de l’IdP d’entreprise, puis l’échanger auprès d’Auth0 contre un jeton d’accès. Cet article présente les deux étapes : obtenir l’ID-JAG (au moyen de SAML ou d’OIDC) et l’envoyer au point de terminaison /token d’Auth0 afin d’obtenir un jeton d’accès pour votre API. Vous pouvez tester le flux XAA manuellement ou à l’aide de notre environnement isolé en ligne (recommandé). Une fois le flux XAA testé, publiez votre application de ressources dans l’Okta Integration Network (OIN) afin d’améliorer la découvrabilité de votre application auprès de vos clients d’entreprise.

(Recommandé) Tester avec notre environnement isolé en ligne

Nous vous recommandons d’utiliser XAA.dev pour tester Cross App Access dans votre navigateur. Suivez les instructions pour tester votre application de ressources avec XAA.dev, qui fait office d’application demandeuse hébergée et qui vous permet d’obtenir un ID-JAG au moyen d’OIDC ou de SAML, selon votre connexion IdP, afin de l’échanger avec votre application de ressources.

Tester manuellement

Obtenir l’ID-JAG

Il existe deux façons d’obtenir un ID-JAG, selon que l’application demandeuse s’authentifie auprès de votre IdP d’entreprise à l’aide de SAML ou d’OIDC.

Application demandeuse SAML

Commencez par vous connecter à votre application demandeuse à l’aide de votre tenant IdP. Une fois connecté, l’IdP redirige le navigateur vers votre application demandeuse avec une réponse SAML. Votre application demandeuse échange ensuite de façon sécurisée l’assertion SAML contenue dans la réponse SAML contre un refresh_token OIDC, puis échange le refresh_token contre un ID-JAG.

Réponse SAML => Assertion SAML => refresh_token => ID-JAG

Une fois la réponse SAML reçue de l’IdP, extrayez l’assertion SAML à l’aide d’une bibliothèque SAML. Voici un exemple de réponse SAML :

<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response Destination="http://localhost:3000/saml/callback" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
        ...
    </saml2:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        ...
    </ds:Signature>
    <saml2p:Status xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </saml2p:Status>
    <!-- Début de l'assertion -->
    <saml2:Assertion Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
        ...
    </saml2:Assertion>
    <!-- Fin de l'assertion -->
</saml2p:Response>

Vous pouvez utiliser l’outil de ligne de commande xmllint pour extraire l’assertion SAML :

saml_xml=$(printf '%s' "${saml_response}" | base64 -d 2>/dev/null)
saml_assertion=$(printf '%s' "${saml_xml}" | xmllint --nsclean --xpath "//*[local-name()='Assertion']" - 2>/dev/null)
subject_token=$(printf '%s' "${saml_assertion}" | base64 | tr -d '\n')

Pour échanger l’assertion SAML contre un jeton d’actualisation OIDC, l’application demandeuse envoie une requête d’échange de jetons au point de terminaison /token de votre IdP avec les paramètres suivants :

POST /oauth2/v1/token HTTP/1.1
Host: {{YOUR_IDP_DOMAIN}}
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token_type=urn:ietf:params:oauth:token-type:saml2
&requested_token_type=urn:ietf:params:oauth:token-type:refresh_token
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&scope=openid offline_access
&subject_token={{SAML_ASSERTION_BASE64}}
&client_id={{CLIENT_ID_IN_IDP}}
&client_secret={{CLIENT_SECRET_IN_IDP}}
&client_assertion={{PRIVATE_KEY_JWT_CLIENT_ASSERTION}}

Paramètre	Description
`grant_type`	Le type d’autorisation. Définissez-le sur le type d’autorisation d’échange de jetons : `urn:ietf:params:oauth:grant-type:token-exchange`.
`subject_token_type`	Le type de jeton fourni dans le paramètre `subject_token`. Définissez-le sur `urn:ietf:params:oauth:token-type:saml2` pour indiquer qu’une assertion SAML est présentée.
`requested_token_type`	Le type de jeton que le client souhaite recevoir du serveur d’autorisation. Définissez-le sur `urn:ietf:params:oauth:token-type:refresh_token`.
`scope`	Valeur fixe. Définissez-la sur `openid offline_access`.
`subject_token`	L’assertion SAML extraite de la réponse SAML, encodée en base64.
`client_id`	L’ID client de l’application demandeuse dans l’IdP d’entreprise qui effectue la requête d’échange de jetons.
`client_secret`	(Facultatif) Le secret client que l’application demandeuse utilise pour s’authentifier auprès de l’IdP d’entreprise.
`client_assertion`	(Facultatif) L’assertion client, qui peut être utilisée pour authentifier l’application demandeuse au moyen de Private Key JWT.
`client_assertion_type`	(Facultatif) Le type d’assertion client. Pour Private Key JWT, définissez-le sur `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.

Si le client IdP est confidentiel, client_secret ou client_assertion est envoyé dans le Form Post ou les en-têtes HTTP; ils s’excluent donc mutuellement et sont indiqués comme facultatifs. Lorsque la requête est réussie, refresh_token est renvoyé dans la propriété access_token de la réponse JSON :

{
  "token_type": "N_A",
  "expires_in": 2592000,
  "access_token": "4SsoXJDBgcq0xxxxxxYn2K-p5l_GCdo",
  "scope": "openid offline_access",
  "issued_token_type": "urn:ietf:params:oauth:token-type:refresh_token"
}

Pour échanger le refresh_token contre un ID-JAG, envoyez une autre requête d’échange de jetons au point de terminaison /token de votre IdP avec les paramètres suivants :

POST /oauth2/v1/token HTTP/1.1
Host: {{YOUR_IDP_DOMAIN}}
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
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&subject_token_type=urn:ietf:params:oauth:token-type:refresh_token
&audience={{YOUR_AUTH0_TENANT_ISSUER_URL}}
&scope={{YOUR_AUTH0_API_SCOPE}}
&subject_token={{REFRESH_TOKEN}}
&client_id={{CLIENT_ID_IN_IDP}}
&client_secret={{CLIENT_SECRET_IN_IDP}}
&client_assertion={{PRIVATE_KEY_JWT_CLIENT_ASSERTION}}

Paramètre	Description
`grant_type`	Le type d’autorisation. Définissez-le sur le type d’autorisation d’échange de jeton : `urn:ietf:params:oauth:grant-type:token-exchange`.
`requested_token_type`	Le type de jeton que le client souhaite recevoir du serveur d’autorisation. Définissez-le sur le grant d’autorisation d’assertion d’identité, ou ID-JAG : `urn:ietf:params:oauth:token-type:id-jag`.
`subject_token_type`	Le type de jeton fourni dans le paramètre `subject_token`. Définissez-le sur `urn:ietf:params:oauth:token-type:refresh_token`.
`audience`	Le destinataire prévu du jeton final. Définissez-le sur l’URL de l’émetteur de votre tenant Auth0 ou sur votre application de ressources dont le serveur d’autorisation se trouve à cette URL précise.
`scope`	Facultatif. Les scopes d’API de l’application de ressources auxquels le client souhaite accéder. Lorsque le serveur d’autorisation émet le jeton d’accès final, il y inclut ces scopes.
`subject_token`	Le `refresh_token` obtenu en échange de l’assertion SAML.
`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`	(Facultatif) Le secret client que l’application demandeuse utilise pour s’authentifier auprès de l’IdP d’entreprise.
`client_assertion`	(Facultatif) L’assertion client, utilisée pour authentifier l’application demandeuse au moyen de Private Key JWT.
`client_assertion_type`	(Facultatif) Le type d’assertion client. Pour Private Key JWT, définissez-le sur `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.

Si le client IdP est confidentiel, client_secret ou client_assertion est envoyé dans le Form Post ou les en-têtes HTTP; ils s’excluent donc mutuellement et sont tous deux marqués comme facultatifs. La réponse à cette requête contient l’ID-JAG dans la propriété access_token :

{
  "token_type": "N_A",
  "expires_in": 300,
  "access_token": "eyJraWQiOiJFeEwySxxxx",
  "issued_token_type": "urn:ietf:params:oauth:token-type:id-jag"
}

L’ID-JAG suit un format JWT, comme dans l’exemple suivant :

{
  "jti": "IDAAG.jrdCpdgazbi52j3UxXT_MqgAUMW2n57EZq8RG0ucRnU",
  "iss": "https://integrator-4598441.okta.com",
  "aud": "https://amin.jp.auth0.com/",
  "iat": 1784620622,
  "exp": 1784620922,
  "sub": "00u14j584jskYLAVs698",
  "email": "test-xaa@example.com",
  "client_id": "Josz8cBBCWKA6Q7CkhyhYjbKY4hqjXMG",
  "sub_profile": "user",
  "scope": "read",
  "act": {
    "sub": "wlp15fk3702lJwVLG698",
    "sub_profile": "ai_agent"
  },
  "sub_id": {
    "format": "saml-nameid",
    "issuer": "http://www.okta.com/exk15fjrhugHeRpO1698",
    "nameid": "test-xaa@example.com",
    "nameid_format": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
  }
}

Lorsque l’application de ressource est une application SAML, l’ID-JAG comprend également une revendication sub_id contenant les renseignements SAML NameID (format, issuer, nameid et nameid_format) de l’utilisateur authentifié, en plus de la revendication sub standard.

Application demandeuse OIDC

Commencez par vous connecter à votre application demandeuse à l’aide de votre tenant IdP. Une fois la connexion réussie, l’IdP redirige le navigateur vers votre application demandeuse avec un code d’autorisation. Votre application demandeuse échange ensuite de façon sécurisée ce code contre un jeton d’accès et un jeton ID.

Jeton ID => ID-JAG

Pour échanger le jeton ID contre un ID-JAG, l’application demandeuse envoie une requête d’échange de jetons au point de terminaison /token de votre IdP avec les paramètres suivants :

POST /oauth2/v1/token HTTP/1.1
Host: {{YOUR_IDP_DOMAIN}}
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
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&audience={{YOUR_AUTH0_TENANT_ISSUER_URL}}
&scope={{YOUR_AUTH0_API_SCOPE}}
&subject_token={{IDP_ID_TOKEN}}
&client_id={{CLIENT_ID_IN_IDP}}
&client_secret={{CLIENT_SECRET_IN_IDP}}
&client_assertion={{PRIVATE_KEY_JWT_CLIENT_ASSERTION}}

Paramètre	Description
`grant_type`	Le type d’autorisation. Définissez-le sur le type d’autorisation d’échange de jetons : `urn:ietf:params:oauth:grant-type:token-exchange`.
`requested_token_type`	Le type de jeton que le client souhaite recevoir du serveur d’autorisation. Définissez-le sur le grant d’autorisation d’assertion d’identité, ou ID-JAG : `urn:ietf:params:oauth:token-type:id-jag`.
`client_assertion_type`	(Facultatif) Le type de l’assertion client. Pour Private Key JWT, définissez-le sur `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.
`subject_token_type`	Le type de jeton fourni dans le paramètre `subject_token`. Pour XAA, il indique qu’un jeton ID est présenté au serveur d’autorisation.
`audience`	Le destinataire prévu du jeton final. Définissez-le sur l’URL d’émetteur de votre tenant Auth0 ou sur votre application de ressources, dont le serveur d’autorisation se trouve à cette URL précise.
`scope`	Facultatif. Le ou les scopes d’API de l’application de ressources auxquelles le client souhaite accéder. Lorsque le serveur d’autorisation émet le jeton d’accès final, il y inclut ces scopes.
`subject_token`	Le jeton que le client échange. Pour XAA, le jeton de sujet constitue la « preuve » ou l’« assertion » de l’identité de l’utilisateur. Définissez-le sur le jeton ID de l’IdP, que l’IdP utilisera pour vérifier l’identité de l’utilisateur.
`client_id`	L’ID client de l’application demandeuse au sein de l’IdP d’entreprise qui effectue la demande d’échange de jetons.
`client_secret`	(Facultatif) Le secret client que l’application demandeuse utilise pour s’authentifier auprès de l’IdP d’entreprise.
`client_assertion`	(Facultatif) L’assertion client, qui peut être utilisée pour authentifier l’application demandeuse au moyen de Private Key JWT.

Si le client IdP est confidentiel, client_secret ou client_assertion est envoyé dans le Form Post ou les en-têtes HTTP; ils s’excluent donc mutuellement et sont marqués comme facultatifs.

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

Une fois que l’application demandeuse obtient un ID-JAG, elle envoie une demande 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}}
&resource={{AUTH0_API_IDENTIFIER}}
&assertion={{ID_JAG}}

Paramètre	Description
`grant_type`	Le type d’autorisation. Il indique au serveur d’autorisation qu’il doit s’attendre à recevoir un JSON Web Token (JWT) comme principal identifiant d’authentification dans la requête.
`client_id`	L’ID client de l’application demandeuse auprès du serveur d’autorisation de l’application de ressources qui effectue l’appel d’API.
`assertion`	L’ID-JAG ou le JSON Web Token (JWT) qui sert de porteur de l’assertion d’identité.
`resource`	(Facultatif) L’identifiant de ressource du serveur de ressources (API) de votre tenant Auth0. Si l’assertion ID-JAG comprend une revendication `resource`, cette valeur prévaut sur ce paramètre. Si aucune ressource n’est précisée dans l’ID-JAG ou dans le corps de la requête, l’audience par défaut de votre tenant est utilisée.
`client_secret`	(Facultatif) Le secret client de l’application demandeuse auprès du serveur d’autorisation de l’application de ressources qui effectue l’appel d’API.
`client_assertion`	(Facultatif) L’assertion client, qui peut être utilisée pour authentifier l’application demandeuse au moyen de Private Key JWT.
`client_assertion_type`	(Facultatif) Le type d’assertion client. Pour Private Key JWT, définissez `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.

Si l’application demandeuse est un client confidentiel, client_secret ou client_assertion est envoyé dans le Form Post ou les en-têtes HTTP ; ils s’excluent donc mutuellement et sont indiqués comme facultatifs. Après avoir validé l’ID-JAG pour vérifier l’identité de l’utilisateur, le serveur d’autorisation Auth0 émet un jeton d’accès pour l’API de votre tenant Auth0. Le jeton d’accès comprend également les scopes demandés, autorisés par 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. L’application demandeuse doit donc 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 par XAA.

Publiez votre application de ressources dans l’OIN

Les fournisseurs B2B et SaaS peuvent élargir leur portée auprès des clients d’entreprise en publiant leur application de ressources dans l’Okta Integration Network (OIN). Pour savoir comment procéder, suivez les instructions de la page How to Build and List Secure Cross App Access Connections on OIN. Pour connaître la liste des champs nécessaires à la publication de votre application de ressources dans l’OIN, consultez vos journaux Auth0 relatifs à idjag-exchange-succeeded.

En savoir plus

Pour vous aider à tester le flux XAA, consultez les ressources suivantes :

Auth0 Cross App Access Inspector : une application Node.js simple qui permet de tester le flux XAA entre Okta et Auth0.
XAA.dev : un environnement isolé en ligne pour tester Cross App Access dans votre navigateur.

Configurer Auth0 comme application de ressources

Configurer Auth0 comme application demandeuse

Tests de bout en bout

(Recommandé) Tester avec notre environnement isolé en ligne

Tester manuellement

Obtenir l’ID-JAG

Application demandeuse SAML

Application demandeuse OIDC

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

Publiez votre application de ressources dans l’OIN

En savoir plus

​(Recommandé) Tester avec notre environnement isolé en ligne

​Tester manuellement

​Obtenir l’ID-JAG

​Application demandeuse SAML

​Application demandeuse OIDC

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

​Publiez votre application de ressources dans l’OIN

​En savoir plus

(Recommandé) Tester avec notre environnement isolé en ligne

Tester manuellement

Obtenir l’ID-JAG

Application demandeuse SAML

Application demandeuse OIDC

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

Publiez votre application de ressources dans l’OIN

En savoir plus