Skip to main content
POST
Ottieni token di accesso MCP di breve durata usando il codice di autorizzazione S256 di un client pubblico o il suo token di aggiornamento corrente.

​
Autenticazione

Nessuna autenticazione HTTP del client. Invia client_id nel corpo con codifica URL. Qualsiasi header Authorization, client_secret o client_assertion viene rifiutato.

​
Corpo della richiesta

​
Esempi di richiesta

Segui la codifica e l’autenticazione documentate per questa route. L’involucro e le regole di idempotenza dell’API delle azioni si applicano solo alle invocazioni di azioni.

​
Risposta

Un token di accesso Bearer opaco, la durata residua in secondi, gli scope concessi e un refresh token quando il client ha registrato refresh_token. expires_in è al massimo 900 e può essere inferiore in prossimità della scadenza dell’autorizzazione.
HTTP 200

​
Intestazioni della risposta

​
Note sull’operazione

  • I parametri scalari riconosciuti devono essere forniti una sola volta come stringhe non vuote, senza caratteri di controllo ASCII o DEL. I campi ripetuti nella query o nel modulo vengono decodificati come array e rifiutati quando vengono letti come scalari.
  • Usa dati di modulo con codifica URL, ad esempio curl —data-urlencode per ciascun campo. Un corpo del token in JSON viene rifiutato con invalid_request.
  • Il destinatario resource è obbligatorio per entrambi i tipi di grant e deve corrispondere esattamente all’URL MCP dell’ambiente che ha emesso il codice o il token di aggiornamento.
  • Lo scambio del codice di autorizzazione richiede il client_id originale, l’esatto redirect_uri e il code_verifier S256 corrispondente. I codici scadono dopo 2 minuti e sono monouso.
  • L’endpoint dei token rifiuta qualsiasi header Authorization fornito, inclusi Basic e Bearer, oltre a qualsiasi campo client_secret o client_assertion nel corpo.
  • I token di accesso durano al massimo 15 minuti. Con refresh_token registrato, la connessione e la famiglia di refresh token scadono 30 giorni dopo l’approvazione dell’utente; la rotazione non prolunga tale scadenza.
  • La restituzione di refresh_token dipende dai tipi di concessione registrati. Non dipende dall’inclusione di offline_access nella richiesta di autorizzazione. Lo scope restituito aggiunge offline_access ogni volta che viene restituito un token di aggiornamento.
  • Per rinnovare, invia grant_type=refresh_token con client_id, il refresh_token corrente, resource e, facoltativamente, uno scope più ristretto. Sostituisci in modo atomico il refresh token archiviato con il nuovo valore.
  • Il riutilizzo di un codice di autorizzazione già consumato o di un token di aggiornamento ruotato revoca l’intera connessione, inclusi tutti i relativi token di accesso. Non riscattare contemporaneamente lo stesso codice o token di aggiornamento.
  • Le richieste di rinnovo non aggiungono mai autorizzazioni. Con uno scope esplicito vengono conservate solo le autorizzazioni di prodotto e identità richieste; offline_access non conserva le autorizzazioni di prodotto omesse.
  • I token sono vincolati all’utente che concede l’autorizzazione, al client, all’audience della risorsa, alla proprietà corrente del team e all’accesso a pagamento attivo. Un’autorizzazione revocata o un cambio di proprietà richiedono una nuova connessione.
  • Il limite pubblico per i token è di 60 richieste al minuto per IP del client, condiviso tra i worker. I corpi con codifica URL sono limitati a 32 KiB.
  • Gli errori OAuth restituiscono error e error_description. Gli errori del parser del corpo possono essere restituiti prima, nel formato di errore del parser dell’integrazione.
  • openid ed email sono autorizzazioni di identità, separate da quelle del prodotto, accettate solo se dichiarate. email richiede openid. Durante l’autorizzazione iniziale, una richiesta con soli ambiti di identità usa le autorizzazioni di prodotto predefinite mostrate nella schermata di consenso.
  • Il client_id restituito dalla registrazione dinamica o l’URL HTTPS pubblico esatto del documento di metadati del client.
  • Quando openid è concesso, lo scambio del codice di autorizzazione restituisce anche un id_token firmato con RS256. Verifica firma, emittente, destinatario, scadenza e nonce, se fornito. Gli ambiti di identità concessi compaiono in scope della risposta; il rinnovo non emette un nuovo id_token.
  • Se OpenID Connect diventa indisponibile, il rinnovo senza scope conserva le autorizzazioni di prodotto e rimuove quelle di identità. Richiedere esplicitamente ambiti di identità indisponibili restituisce invalid_scope.
  • Se l’account è stato eliminato o disattivato, l’endpoint dei token restituisce invalid_grant con HTTP 400.

​
Errori