Token exchange

FoxIDs prend en charge deux scénarios différents d’échange de jetons : échange de jetons dans le même environnement et échange de jetons via la confiance.

Dans le même environnement, il est possible d’échanger des access tokens dans une application web ou une API/ressource vers une autre ressource.

Par confiance externe, il est possible d’échanger des access tokens externes et des jetons SAML 2.0 en access tokens internes.

Samples

L’échange de jetons est implémenté dans les exemples suivants :

Vous pouvez tester l’échange de jetons avec l’exemple d’application web en ligne (doc de l’exemple) en cliquant sur Log in et en vous connectant avec un IdP optionnel. Cliquez ensuite sur Call API1 which call API2 ou Token Exchange + Call Api2 pour appeler une API en utilisant l’échange de jetons.
Jetez un œil à la configuration de l’exemple dans FoxIDs Control : https://control.foxids.com/test-corp
Obtenez un accès en lecture avec l’utilisateur reader@foxids.com et le mot de passe gEh#V6kSw

Configuration de l’enregistrement d’application

Il est possible de configurer si l’échange de jetons est autorisé sur l’enregistrement d’application OAuth 2.0 ou le client OpenID Connect. De même, il est possible de configurer si le client credentials grant doit être autorisé. Par défaut, le client credentials grant et l’échange de jetons sont autorisés sur les enregistrements d’application OAuth 2.0 et les clients OpenID Connect.
Par défaut, le client est ajouté en tant qu’acteur d’échange de jeton ; ce comportement peut être désactivé.

OAuth 2.0 client config

Échange de jetons dans le même environnement

Il est possible d’échanger un access token émis pour une ressource et d’obtenir ainsi un access token pour une autre ressource dans l’environnement.
Un client d’enregistrement d’application est configuré pour gérer l’échange de jetons et pour définir une liste blanche des ressources pour lesquelles il est autorisé à effectuer un échange de jetons.

Access Token vers Access Token dans une application web

Une application web échange un access token JWT vers un access token JWT' dans le même environnement.

Dans ce scénario, un client OpenID Connect a obtenu un access token après authentification utilisateur.
Le client peut également être un client OAuth 2.0 utilisant le client credentials grant.

Token exchange, Access token to Access token in web application

L’environnement inclut deux ressources et le client OpenID Connect est autorisé à appeler directement la première et la deuxième ressource. Pour appliquer le moindre privilège, le client OpenID Connect n’obtient un access token que pour la première ressource après authentification utilisateur. Ensuite, il obtient un access token pour la deuxième ressource lorsque nécessaire.

OpenID Connect client client - resource scopes

Le premier access token est émis avec un scope/audience pour le client OpenID Connect et le client est ainsi autorisé à échanger les access tokens vers un access token' valable pour la deuxième ressource.
Le client OpenID Connect est configuré avec un secret en tant que client credentials utilisé à la fois dans la communication OpenID Connect et l’échange de jetons.

Pendant la séquence d’échange de jetons, les transformations et limitations des claims sont exécutées sur l’enregistrement d’application OpenID Connect.

Le client OpenID Connect effectue un appel d’échange de jetons vers FoxIDs en authentifiant le client et en transmettant l’access token tout en demandant (avec un scope) un access token' pour la deuxième ressource. En cas de succès, le client de ressource reçoit un access token' et peut maintenant appeler la deuxième ressource avec cet access token'.

Exemple de requête POST d’échange de jetons vers le endpoint token :

POST https://foxids.com/test-corp/-/aspnet_oidc_allup_online_sample(*)/oauth/token HTTP/1.1
Host: foxids.com
Content-Type: application/x-www-form-urlencoded

client_id=aspnet_oidc_allup_sample
&client_secret=IxIruKswG4sQxzOrKlXR58strgZtoyZPG18J3FhzEXI
&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&scope=aspnetcore_api2_sample%3Asome_2_access
&subject_token=accVkjcJyb4...UC5PbRDqceLTC
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

Exemple de réponse JSON d’échange de jetons :

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
    "access_token":"eyJhGcjlc...nNjb3IIWvmDCM",
    "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
    "token_type":"Bearer",
    "expires_in":600
}

Exemple de corps d’access token JWT' :

{
    "sub": "2f18c344-1204-4629-b992-215913b85c2b",
    "auth_time": "1699955593",
    "amr": "pwd",
    "email": "test1@foxids.com",
    "role": ["role1","role2"],
    "name": "Test 1 user",
    "act": "{\"sub\":\"c_aspnet_oidc_allup_sample\"}",
    "scope": "aspnetcore_api2_sample:some_2_access",
    "client_id": "aspnet_oidc_allup_sample",
    "nbf": 1699955534,
    "exp": 1699956194,
    "iat": 1699955594,
    "iss": "https://foxids.com/test-corp/-/",
    "aud": "aspnetcore_api2_sample"
}

Access Token vers Access Token dans une API

Une API échange un access token JWT vers un access token JWT' dans le même environnement.

Dans ce scénario, un client OpenID Connect a obtenu un access token après authentification utilisateur.
Le client peut également être un client OAuth 2.0 utilisant le client credentials grant.

Token exchange, Access token to Access token in API

L’environnement inclut deux ressources et le client OpenID Connect est autorisé à appeler directement la première ressource. Le client OpenID Connect n’est PAS autorisé à appeler directement la deuxième ressource. Sur la première ressource, un client est configuré permettant d’échanger des access tokens avec l’audience client/ressource vers un access token' valable pour la deuxième ressource.
Le client « flowing » sur la première ressource est configuré avec un certificat comme client credential.

OAuth 2.0 client on the first resource

Pendant la séquence d’échange de jetons, les transformations et limitations des claims sont exécutées sur l’enregistrement d’application.

Le client OpenID Connect appelle la première ressource avec l’access token obtenu. Le client de ressource effectue un appel d’échange de jetons vers FoxIDs en authentifiant le client et en transmettant l’access token tout en demandant (avec un scope) un access token' pour la deuxième ressource. En cas de succès, le client de ressource reçoit un access token' et peut maintenant appeler la deuxième ressource avec cet access token'.

Exemple de requête POST d’échange de jetons vers le endpoint token :

POST https://foxids.com/test-corp/-/aspnet_oidc_allup_online_sample(*)/oauth/token HTTP/1.1
Host: foxids.com
Content-Type: application/x-www-form-urlencoded

client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiI...kyX3NhbXBsZS
&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&scope=aspnetcore_api2_sample%3Asome_2_access
&subject_token=accVkjcJyb4...C5PbRDqceLTC
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

Exemple de réponse JSON d’échange de jetons :

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
    "access_token":"eyJhGcRwczov...nNjb3BlIjoi",
    "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
    "token_type":"Bearer",
    "expires_in":600
}

Exemple de corps d’access token JWT' :

{
    "sub": "2f18c344-1204-4629-b992-215913b85c2b",
    "auth_time": "1699955841",
    "amr": "pwd",
    "act": "{\"sub\":\"c_aspnetcore_api1_sample\"}",
    "scope": "aspnetcore_api2_sample:some_2_access",
    "client_id": "aspnetcore_api1_sample",
    "nbf": 1699955786,
    "exp": 1699956446,
    "iat": 1699955846,
    "iss": "https://foxids.com/test-corp/-/",
    "aud": "aspnetcore_api2_sample"
}

Échange de jetons par confiance

Par confiance externe envers un IdP/OP, il est possible d’échanger un access token ou un jeton SAML 2.0 émis par une partie externe (ou un autre environnement FoxIDs) et d’obtenir ainsi un access token pour une ressource dans l’environnement.
Une confiance de méthode d’authentification est configurée et un client d’enregistrement d’application est configuré pour autoriser l’échange de jetons en fonction des confiances de méthode d’authentification. Le client d’enregistrement d’application met en outre en liste blanche les ressources de l’environnement pour lesquelles il est autorisé à effectuer un échange de jetons.

Il est possible de configurer si la confiance de méthode d’authentification doit être autorisée pour l’échange de jetons et l’authentification utilisateur. Par défaut, les deux sont autorisés pour les confiances de méthode d’authentification OAuth 2.0, OpenID Connect et SAML 2.0.

OAuth 2.0 trust config

Access Token vers Access Token par confiance

Échange d’un access token JWT externe vers un access token JWT interne par confiance externe.

Dans ce scénario, un client OpenID Connect fait confiance à un fournisseur OpenID (OP) / fournisseur d’identité (IdP) externe et a obtenu un access token après authentification utilisateur.
Le client peut également être un client OAuth 2.0 utilisant le client credentials grant pour obtenir l’access token externe.

Token exchange, Access token to Access token by trust

Il existe une ressource dans l’environnement mais le client OpenID Connect externe défini n’est PAS autorisé à appeler directement la ressource.
D’abord, une méthode d’authentification OAuth 2.0 ou OpenID Connect est configurée pour faire confiance au fournisseur OpenID (OP) / fournisseur d’identité (IdP) externe et l’émetteur SP est configuré pour correspondre à l’audience du client OpenID Connect externe.
L’exemple de confiance externe suivant est une confiance envers un autre environnement FoxIDs.

OAuth 2.0 authentication method trust

Ensuite, un client d’enregistrement d’application OAuth 2.0 est configuré pour accepter des access tokens externes via la confiance de méthode d’authentification. Il est possible d’avoir une ou plusieurs confiances de méthode d’authentification.
Le client « flowing » est configuré avec un secret comme client credential.

OAuth 2.0 application registration client for OIDC application

Il est ainsi possible d’échanger un access token externe vers un access token interne valable pour la ressource.

Pendant la séquence d’échange de jetons, les transformations et limitations des claims sont exécutées d’abord sur la méthode d’authentification puis sur l’enregistrement d’application.

L’application backend client OpenID Connect effectue un appel d’échange de jetons vers FoxIDs, en authentifiant le client OAuth 2.0 interne et en transmettant l’access token externe tout en demandant (avec un scope) un access token pour la ressource. En cas de succès, l’application backend client OpenID Connect reçoit un access token et peut désormais appeler la ressource.

Exemple de requête POST d’échange de jetons vers le endpoint token :

POST https://foxids.com/test-corp/-/aspnet_oidc_allup_online_sample(*)/oauth/token HTTP/1.1
Host: foxids.com
Content-Type: application/x-www-form-urlencoded

client_id=some_external_id
&client_secret=goOxwj8Kz...wUC-3CGs
&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&scope=aspnetcore_api2_sample%3Asome_2_access
&subject_token=accVkjcJyb4...UC5PbRDqceLTC
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

Exemple de réponse JSON d’échange de jetons :

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
    "access_token":"eyJhGcjlc...nNjb3IIWvmDCM",
    "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
    "token_type":"Bearer",
    "expires_in":600
}

SAML 2.0 vers Access Token par confiance

Échange d’un jeton SAML 2.0 externe vers un access token JWT interne par confiance externe.

Dans ce scénario, une application SAML 2.0 fait confiance à un fournisseur d’identité (IdP) externe et a obtenu un jeton SAML 2.0 après authentification utilisateur.

Token exchange, SAML 2.0 to Access token by trust

Il existe une ressource dans l’environnement mais l’application SAML 2.0 externe définie n’est PAS autorisée à appeler directement la ressource.
D’abord, une méthode d’authentification SAML 2.0 est configurée pour faire confiance au fournisseur d’identité (IdP) et l’émetteur SP est configuré pour correspondre à l’audience de l’application SAML 2.0 externe.
L’exemple de confiance externe suivant est une confiance envers un enregistrement d’application SAML 2.0 FoxIDs.

SAML 2.0 authentication method trust

Ensuite, un client d’enregistrement d’application OAuth 2.0 est configuré pour accepter des jetons SAML 2.0 externes via la confiance de méthode d’authentification. Il est possible d’avoir une ou plusieurs confiances de méthode d’authentification.
Le client « flowing » est configuré avec un certificat comme client credential.

OAuth 2.0 application registration client for SAML 2.0 application

Il est ainsi possible d’échanger un jeton SAML 2.0 externe vers un access token interne valable pour la ressource.

Pendant la séquence d’échange de jetons, les transformations et limitations des claims sont exécutées d’abord sur la méthode d’authentification puis sur l’enregistrement d’application.

L’application backend SAML 2.0 effectue un appel d’échange de jetons vers FoxIDs, en authentifiant le client OAuth 2.0 interne et en transmettant le jeton SAML 2.0 externe tout en demandant (avec un scope) un access token pour la ressource. En cas de succès, l’application backend SAML 2.0 reçoit un access token et peut désormais appeler la ressource.

Exemple de requête POST d’échange de jetons vers le endpoint token :

POST https://foxids.com/test-corp/-/aspnet_oidc_allup_online_sample(*)/oauth/token HTTP/1.1
Host: foxids.com
Content-Type: application/x-www-form-urlencoded

client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiI...kyX3NhbXBsZS
&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&scope=aspnetcore_api2_sample%3Asome_2_access
&subject_token=%3Csaml%3AAssertion%20xmlns%3Asaml...%3AAssertion%3E%0A
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Asaml2

Exemple de réponse JSON d’échange de jetons :

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
    "access_token":"eyJhGcRwczov...nNjb3BlIjoi",
    "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
    "token_type":"Bearer",
    "expires_in":600
}

Votre confidentialité

Nous utilisons des cookies pour améliorer votre expérience sur nos sites. Cliquez sur « Accepter tous les cookies » pour accepter l'utilisation des cookies. Pour refuser les cookies non essentiels, cliquez sur « Cookies nécessaires uniquement ».

Consultez notre politique de confidentialité pour en savoir plus