Aller au contenu principal

Jeton d’accès personnel (Personal access token)

Les jetons d’accès personnels (PATs) offrent un moyen sécurisé pour les utilisateurs d’accorder un jeton d’accès (Access token) sans utiliser leurs identifiants et une connexion interactive. Ceci est utile pour les CI/CD, les scripts ou les applications qui doivent accéder aux ressources de manière programmatique.

Gestion des jetons d’accès personnels​

Utilisation de la Console​

Vous pouvez gérer les jetons d’accès personnels dans la page Détails de l’utilisateur du Console > Gestion des utilisateurs. Dans la carte "Authentification (Authentication)", vous pouvez voir la liste des jetons d’accès personnels et en créer de nouveaux.

Utilisation de Management API​

Après avoir configuré le Management API, vous pouvez utiliser les points de terminaison API pour créer, lister et supprimer des jetons d’accès personnels.

Utiliser les PATs pour accorder des jetons d’accès​

Après avoir créé un PAT, vous pouvez l’utiliser pour accorder des jetons d’accès à votre application en utilisant le point de terminaison d’échange de jetons.

Équivalence des flux de jetons:

Les jetons d’accès obtenus à l’aide des PATs fonctionnent exactement comme les jetons obtenus via le flux standard refresh_token. Cela signifie :

  • Contexte d’organisation : Les jetons obtenus via PAT prennent en charge les mêmes permissions d’organisation et portées (scopes) que les flux de jeton de rafraîchissement
  • Flux d’autorisation : Vous pouvez utiliser les jetons d’accès échangés via PAT pour les permissions d’organisation et les ressources API au niveau de l’organisation
  • Validation du jeton : La même logique de validation s’applique — seul le type de grant initial diffère

Si vous travaillez avec des organisations, les modèles d’accès et les permissions sont identiques que vous utilisiez un PAT ou un jeton de rafraîchissement.

Requête​

Prérequis:

Avant d'utiliser la délégation d'échange de jeton, vous devez l'activer pour votre application :

  1. Allez dans Console > Applications et sélectionnez votre application.
  2. Dans les paramètres de l'application, trouvez la section "Échange de jeton".
  3. Activez l'option "Autoriser l'échange de jeton".

L'échange de jeton est désactivé par défaut pour des raisons de sécurité. Si vous ne l'activez pas, vous recevrez une erreur "l'échange de jeton n'est pas autorisé pour cette application".

L’application effectue une requête d’échange de jeton vers le point de terminaison de jeton du tenant avec un type de grant spécial en utilisant la méthode HTTP POST. Les paramètres suivants sont inclus dans le corps de la requête HTTP au format application/x-www-form-urlencoded.

  1. client_id : OBLIGATOIRE. L’ID client de l’application.
  2. grant_type : OBLIGATOIRE. La valeur de ce paramètre doit être urn:ietf:params:oauth:grant-type:token-exchange pour indiquer qu’un échange de jeton est en cours.
  3. resource : OPTIONNEL. L’indicateur de ressource, identique aux autres requêtes de jeton.
  4. scope : OPTIONNEL. Les portées demandées, identiques aux autres requêtes de jeton.
  5. subject_token : OBLIGATOIRE. Le PAT de l’utilisateur.
  6. subject_token_type : OBLIGATOIRE. Le type de jeton de sécurité fourni dans le paramètre subject_token. La valeur de ce paramètre doit être urn:logto:token-type:personal_access_token.

Réponse​

Si la requête d’échange de jeton réussit, le point de terminaison de jeton du tenant retourne un jeton d’accès qui représente l’identité de l’utilisateur. La réponse inclut les paramètres suivants dans le corps de la réponse HTTP au format application/json.

  1. access_token : OBLIGATOIRE. Le jeton d’accès de l’utilisateur, identique aux autres requêtes de jeton comme authorization_code ou refresh_token.
  2. issued_token_type : OBLIGATOIRE. Le type du jeton émis. La valeur de ce paramètre doit être urn:ietf:params:oauth:token-type:access_token.
  3. token_type : OBLIGATOIRE. Le type du jeton. La valeur de ce paramètre doit être Bearer.
  4. expires_in : OBLIGATOIRE. La durée de vie en secondes du jeton d’accès.
  5. scope : OPTIONNEL. Les portées du jeton d’accès.

Exemple d’échange de jeton​

Pour les applications web traditionnelles ou les applications machine à machine avec secret d’application, incluez les identifiants dans l’en-tête Authorization en utilisant l’authentification HTTP Basic :

POST /oidc/token HTTP/1.1
Host: tenant.logto.app
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <base64(app-id:app-secret)>

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&resource=http://my-api.com
&scope=read
&subject_token=pat_W51arOqe7nynW75nWhvYogyc
&subject_token_type=urn:logto:token-type:personal_access_token

Pour les applications monopage (SPA) ou les applications natives sans secret d’application, incluez client_id dans le corps de la requête :

POST /oidc/token HTTP/1.1
Host: tenant.logto.app
Content-Type: application/x-www-form-urlencoded

client_id=your-app-id
&grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&resource=http://my-api.com
&scope=read
&subject_token=pat_W51arOqe7nynW75nWhvYogyc
&subject_token_type=urn:logto:token-type:personal_access_token

Une réponse réussie :

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "eyJhbGci...zg",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read"
}

Si vous décodez ensuite le jeton d’accès avec le décodificateur JWT, vous obtiendrez l’exemple de charge utile suivant :

{
  "jti": "VovNyqJ5_tuYac89eTbpF",
  "sub": "rkxl1ops7gs1",
  "iat": 1756908403,
  "exp": 1756912003,
  "scope": "read",
  "client_id": "your-app-id",
  "iss": "https://tenant-id.logto.app/oidc",
  "aud": "http://my-api.com"
}

Qu’est-ce qu’un jeton d’accès personnel ? Quand dois-je utiliser des jetons d’accès personnels ?

Jetons d’accès personnels, authentification machine à machine et définition des clés API et leurs scénarios réels