Échange de jeton de travailleur privilégié avec Token Vault
Découvrez comment une application peut accéder à Token Vault pour échanger un jeton JWT Bearer contre un jeton d’accès ou un Jeton d’actualisation afin d’appeler des API externes.
Use this file to discover all available pages before exploring further.
L’échange de jeton de travailleur privilégié avec Token Vault est actuellement en version bêta. Pour en savoir plus sur le cycle de versions des produits Auth0, consultez la page Product Release Stages. Pour participer à ce programme, communiquez avec le support Auth0 ou votre gestionnaire de compte technique.
Token Vault prend en charge l’échange de jeton de travailleur privilégié, qui permet à une application cliente d’échanger un JWT signé (jeton sujet) contre un jeton d’accès ou un Jeton d’actualisation d’un fournisseur externe (jeton demandé).Une fois l’authentification et l’autorisation de l’utilisateur réussies, une application cliente transmet généralement le contexte de l’utilisateur, qui contient l’identité de l’utilisateur, ses autorisations et l’état de la session, sous forme de jeton d’accès ou de Jeton d’actualisation pour effectuer l’échange de jeton avec Token Vault. Dans les flux de service à service, une application cliente, comme une application back-end ou un service worker, peut devoir accéder à des ressources au nom de l’utilisateur, mais comme « l’utilisateur n’est pas présent » dans une session interactive, l’application cliente n’a pas accès au contexte de l’utilisateur.Dans ces scénarios de service à service, l’application cliente peut générer un jeton JWT Bearer signé et l’utiliser comme jeton sujet pour effectuer l’échange de jeton et recevoir les jetons nécessaires pour appeler des API externes. Cela signifie que l’application cliente peut effectuer des actions au nom de l’utilisateur sans interaction ni session utilisateur active.Pour utiliser l’échange de jeton de travailleur privilégié avec Token Vault, l’application cliente doit être un client hautement privilégié qui peut également demander des Jetons d’actualisation à des fournisseurs externes via Token Vault. Elle doit s’authentifier auprès de Token Vault à l’aide de méthodes cryptographiques asymétriques, comme une assertion Private Key JWT ou l’authentification TLS mutuelle.
Seuls certains types de clients peuvent utiliser Privileged Worker Token Exchange avec Token Vault :
Le client doit être un client de première partie, c.-à-d. que la propriété is_first_party a la valeur true.
Le client doit être un client confidentiel avec un mécanisme d’authentification valide, c.-à-d. que la propriété token_endpoint_auth_method ne doit pas être définie sur la valeur none.
Le client doit être conforme à OIDC, c.-à-d. que la propriété oidc_conformant doit avoir la valeur true.
Avant de configurer Privileged Worker Token Exchange pour votre application cliente :
Pour configurer l’accès privilégié de l’application cliente à Token Vault, vous devez fournir une clé publique qui sera utilisée pour vérifier un JWT signé utilisé comme subject token.Comme pour la configuration de JAR, vous pouvez définir la clé publique d’accès privilégié de Token Vault lors de la création d’un nouveau client :
POST https://{yourDomain}.auth0.com/api/v2/clientsAuthorization: Bearer <YOUR_MANAGEMENT_API_ACCESS_TOKEN>Content-Type: application/json{ "name": "My App using JAR", “grant_types”: [“urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token”], “oidc_conformant”: true, “is_first_party”: true, “jwt_configuration”: { “alg”: 'RS256', }, "token_vault_privileged_access": {"credentials": [{ "name": "Mes informations d'identification pour l'accès privilégié au coffre de jetons", "credential_type": "public_key", "pem": "<YOUR PEM FILE CONTENT>", "alg": "RS256"}] },}
Vous pouvez également mettre à jour un client existant avec la clé publique d’accès privilégié de Token Vault :
Après avoir configuré votre application cliente avec la clé publique, vous devez créer le jeton de sujet qui sera échangé contre un jeton d’accès pour une API externe. Le jeton de sujet est un JSON Web Token (JWT) contenant les revendications nécessaires. Il est signé avec la clé privée.Le JWT a un format et des revendications standard, où :
Le typ de l’en-tête est token-vault-req+jwt
Le kid de l’en-tête est facultatif si vous n’avez configuré qu’une seule clé publique
Le sub de la charge utile est l’ID de l’utilisateur pour lequel vous voulez obtenir le jeton
Le aud de la charge utile est l’hôte de votre tenant
Le iss de la charge utile est votre ID client qui effectue la requête
Le type d’autorisation. Pour Token Vault, définissez-le sur urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token
client_id
ID de l’application cliente
client_secret
Secret client. Remarque : pour Privileged Worker Token Exchange, nous recommandons d’utiliser l’authentification Private Key JWT ou mTLS.
subject_token_type
Type de jeton du sujet. Pour Privileged Worker Token Exchange, définissez-le sur JWT : urn:ietf:params:oauth:token-type:jwt
subject_token
Le jeton porteur JWT signé que le Serveur d’autorisation Auth0 valide pour identifier l’utilisateur.
requested_token_type
Le type de jeton demandé. Pour Privileged Worker Token Exchange, vous pouvez demander un jeton d’accès ou un jeton d’actualisation.
connection
Le nom de la connexion, dans ce cas, google-oauth2.
Vous devriez recevoir le jeton d’accès stocké dans le Token Vault. Vous pouvez de la même manière demander le jeton d’actualisation pour l’API externe :
