Skip to main content
GET
Scopri gli endpoint OAuth pubblici e i meccanismi di codice di autorizzazione, PKCE, aggiornamento e revoca supportati da questo ambiente.

Autenticazione

Nessuna.

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

Metadati del server di autorizzazione OAuth con URL assoluti degli endpoint sull’origine canonica dell’emittente.
HTTP 200

Note sull’operazione

  • Sono dichiarati soltanto il tipo di risposta code e la modalità di risposta query.
  • I client possono usare la registrazione dinamica o un Client ID Metadata Document (CIMD). client_id_metadata_document_supported è true; un client CIMD usa l’URL HTTPS pubblico del documento come client_id.
  • Un documento JSON CIMD deve contenere un client_id identico, un client_name non vuoto di massimo 120 caratteri e 1–10 redirect_uris esatti. Usa l’autenticazione del client pubblico none con S256 PKCE; authorization_code è obbligatorio e refresh_token è facoltativo.
  • Servi il CIMD come JSON non compresso su HTTPS pubblico sulla porta 443, con un percorso esplicito, senza credenziali, frammenti, segmenti punto o reindirizzamenti. Il documento deve essere al massimo di 64 KiB e rispondere entro 5 secondi. I metadati in cache scadono entro 5 minuti; scambio e rinnovo dei token usano i metadati associati all’autorizzazione.
  • Quando OpenID Connect è disponibile, i metadati del server di autorizzazione dichiarano anche gli ambiti openid ed email, userinfo_endpoint e jwks_uri. Altrimenti questi ambiti ed endpoint sono assenti dai metadati.
  • I metodi di autenticazione per token e revoca sono none. I client pubblici usano client_id e S256 PKCE al posto di un segreto client.
  • offline_access è un indicatore di scope relativo al rinnovo, non un’autorizzazione del prodotto. L’emissione di un token di aggiornamento dipende dalla registrazione di refresh_token come tipo di grant.
  • Verifica che il valore iss restituito nel callback finale del client corrisponda a issuer. Sia i callback di autorizzazione riuscita sia quelli di autorizzazione negata includono iss e riportano state quando è stato fornito.

Errori