Skip to main content
POST
Obtenez des jetons d’accès MCP de courte durée à l’aide du code d’autorisation S256 d’un client public ou de son jeton d’actualisation actuel.

​
Authentification

Aucune authentification du client HTTP. Envoyez client_id dans le corps encodé en URL. Tout en-tête Authorization et tout champ client_secret ou client_assertion sont rejetés.

​
Corps de la requête

​
Exemples de requêtes

Suivez l’encodage et l’authentification documentés pour cette route. L’enveloppe et les règles d’idempotence de l’API d’actions s’appliquent uniquement aux invocations d’actions.

​
Réponse

Un jeton d’accès Bearer opaque, sa durée de validité restante en secondes, les autorisations accordées et un jeton d’actualisation si le client a enregistré refresh_token. expires_in vaut au maximum 900 et peut être inférieur à l’approche de l’expiration de l’autorisation.
HTTP 200

​
En-têtes de réponse

​
Notes de l’opération

  • Les paramètres scalaires reconnus doivent être fournis une seule fois, sous forme de chaînes non vides sans caractères de contrôle ASCII ni DEL. Les champs de requête ou de formulaire répétés sont décodés en tableaux et rejetés lorsqu’ils sont lus comme des scalaires.
  • Utilisez des données de formulaire encodées en URL, par exemple curl —data-urlencode pour chaque champ. Un corps de jeton en JSON est rejeté avec invalid_request.
  • L’audience resource est obligatoire pour les deux types d’autorisation et doit correspondre exactement à l’URL MCP de l’environnement ayant émis le code ou le jeton d’actualisation.
  • L’échange du code d’autorisation nécessite le client_id d’origine, le redirect_uri exact et le code_verifier S256 correspondant. Les codes expirent après 2 minutes et sont à usage unique.
  • Le point de terminaison des jetons rejette tout en-tête Authorization fourni, y compris Basic et Bearer, ainsi que tout champ client_secret ou client_assertion dans le corps.
  • Les jetons d’accès restent valides au maximum 15 minutes. Lorsque refresh_token est enregistré, la connexion et la famille de jetons d’actualisation expirent 30 jours après l’approbation de l’utilisateur ; le renouvellement ne prolonge pas cette échéance.
  • Le renvoi de refresh_token dépend des types d’octroi enregistrés. Il ne dépend pas de l’inclusion de offline_access dans la requête d’autorisation. Le champ scope renvoyé inclut offline_access chaque fois qu’un jeton d’actualisation est renvoyé.
  • Pour renouveler, envoyez grant_type=refresh_token avec client_id, le refresh_token actuel, resource et, facultativement, un scope restreint. Remplacez de façon atomique le jeton d’actualisation stocké par la nouvelle valeur.
  • Réutiliser un code d’autorisation déjà consommé ou un jeton d’actualisation remplacé révoque toute la connexion, y compris tous ses jetons d’accès. N’échangez pas simultanément le même code ou jeton d’actualisation.
  • Le renouvellement n’ajoute jamais de permissions. Avec un scope explicite, seules les permissions produit et d’identité demandées sont conservées ; offline_access ne conserve pas les permissions produit omises.
  • Les jetons sont liés à l’utilisateur qui les a autorisés, au client, à l’audience de la ressource, au propriétaire actuel de l’équipe et à l’accès payant actif. Une autorisation révoquée ou un changement de propriétaire impose une reconnexion.
  • La limite publique des jetons est de 60 requêtes par minute et par adresse IP client, partagée entre les workers. Les corps encodés en URL sont limités à 32 KiB.
  • Les échecs OAuth renvoient error et error_description. Les échecs d’analyse du corps peuvent être renvoyés plus tôt au format d’erreur de l’analyseur d’intégration.
  • openid et email sont des permissions d’identité, distinctes des permissions produit, acceptées uniquement lorsqu’elles sont annoncées. email nécessite openid. Lors de l’autorisation initiale, une demande contenant seulement des permissions d’identité utilise les permissions produit par défaut affichées sur l’écran de consentement.
  • Le client_id renvoyé par l’enregistrement dynamique ou l’URL HTTPS publique exacte du document de métadonnées du client.
  • Quand openid est accordé, l’échange du code d’autorisation renvoie aussi un id_token signé avec RS256. Vérifiez sa signature, son émetteur, son audience, son expiration et le nonce s’il a été fourni. Les permissions d’identité accordées figurent dans scope de la réponse ; le renouvellement n’émet pas de nouvel id_token.
  • Si OpenID Connect devient indisponible, un renouvellement sans scope conserve les permissions produit et retire celles d’identité. Demander explicitement des permissions d’identité indisponibles renvoie invalid_scope.
  • Si le compte a été supprimé ou désactivé, l’endpoint de tokens renvoie invalid_grant avec HTTP 400.

​
Erreurs