Passa al contenuto principale

3. Obtaining Authorization Server Metadata (Ottenimento dei metadati del server di autorizzazione)

I server di autorizzazione che supportano i metadati devono (MUST) rendere disponibile un documento JSON contenente i metadati specificati nella sezione 2 in un percorso formato inserendo una stringa URI nota (well-known) tra il componente host e il componente percorso (se presente) dell'identificatore dell'emittente del server di autorizzazione. Per impostazione predefinita, la stringa URI nota utilizzata è /.well-known/oauth-authorization-server. Questo percorso deve (MUST) utilizzare lo schema "https". La sintassi e la semantica di ".well-known" sono definite in RFC 5785 [RFC5785]. Il suffisso URI noto utilizzato deve (MUST) essere registrato nel registro IANA "Well-Known URIs" [IANA.well-known].

Diverse applicazioni che utilizzano un server di autorizzazione OAuth in modo specifico per l'applicazione possono (MAY) definire e registrare diversi suffissi URI noti utilizzati per pubblicare i metadati del server di autorizzazione utilizzati da tali applicazioni. Ad esempio, se un'applicazione di esempio utilizza un server di autorizzazione OAuth in modo specifico per l'esempio e deve pubblicare valori di metadati specifici per l'esempio, potrebbe registrare e utilizzare il suffisso URI "example-configuration" e pubblicare il documento dei metadati inserendo /.well-known/example-configuration tra i componenti host e percorso dell'identificatore dell'emittente del server di autorizzazione. In alternativa, molte di tali applicazioni utilizzeranno la stringa URI nota predefinita /.well-known/oauth-authorization-server, che è la scelta appropriata per i server di autorizzazione OAuth generici, e non registreranno una stringa specifica per l'applicazione.

Le applicazioni OAuth 2.0 che utilizzano questa specifica devono (MUST) specificare quale suffisso URI noto utilizzeranno a questo scopo. Lo stesso server di autorizzazione può (MAY) scegliere di pubblicare i suoi metadati in più posizioni note derivate dal suo identificatore dell'emittente, ad esempio pubblicandoli sia in /.well-known/example-configuration che in /.well-known/oauth-authorization-server.

Alcune applicazioni OAuth sceglieranno di utilizzare il suffisso URI noto "openid-configuration". Come indicato nella sezione 5, sebbene l'identificatore /.well-known/openid-configuration sembri specifico di OpenID, il suo utilizzo in questa specifica si riferisce effettivamente a una funzionalità OAuth 2.0 generale e non è specifico di OpenID Connect.

3.1. Authorization Server Metadata Request (Richiesta di metadati del server di autorizzazione)​

Il documento dei metadati del server di autorizzazione deve (MUST) essere interrogato utilizzando una richiesta HTTP "GET" al percorso precedentemente specificato.

Quando l'identificatore dell'emittente è https://example.com e il suffisso URI noto è "oauth-authorization-server", il client effettuerà la seguente richiesta per ottenere i metadati, poiché l'identificatore dell'emittente non contiene un componente percorso:

GET /.well-known/oauth-authorization-server HTTP/1.1
Host: example.com

Se il valore dell'identificatore dell'emittente contiene un componente percorso, qualsiasi "/" finale deve (MUST) essere rimosso prima di inserire /.well-known/ e il suffisso URI noto tra i componenti host e percorso. Quando l'identificatore dell'emittente è https://example.com/issuer1 e il suffisso URI noto è "oauth-authorization-server", il client effettuerà la seguente richiesta per ottenere i metadati, poiché l'identificatore dell'emittente contiene un componente percorso:

GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com

L'uso di componenti percorso consente il supporto di più emittenti per host. Questo è necessario in alcune configurazioni di hosting multi-tenant. Questo utilizzo di ".well-known" è destinato a supportare più emittenti per host; a differenza del suo utilizzo in RFC 5785 [RFC5785], non fornisce informazioni generali sull'host.

3.2. Authorization Server Metadata Response (Risposta dei metadati del server di autorizzazione)​

La risposta è un insieme di rivendicazioni sulla configurazione del server di autorizzazione, inclusi tutti gli endpoint necessari e le informazioni sulla posizione delle chiavi pubbliche. Una risposta di successo deve (MUST) utilizzare il codice di stato HTTP 200 OK e restituire un oggetto JSON utilizzando il tipo di contenuto "application/json" che contiene un insieme di rivendicazioni come suoi membri che sono un sottoinsieme dei valori di metadati definiti nella sezione 2. Altre rivendicazioni possono (MAY) anche essere restituite.

Le rivendicazioni che restituiscono più valori sono rappresentate come array JSON. Le rivendicazioni con zero elementi devono (MUST) essere omesse dalla risposta.

Le risposte di errore utilizzano valori di codice di stato HTTP applicabili.

Il seguente è un esempio di risposta non normativo:

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

{
 "issuer":
   "https://server.example.com",
 "authorization_endpoint":
   "https://server.example.com/authorize",
 "token_endpoint":
   "https://server.example.com/token",
 "token_endpoint_auth_methods_supported":
   ["client_secret_basic", "private_key_jwt"],
 "token_endpoint_auth_signing_alg_values_supported":
   ["RS256", "ES256"],
 "userinfo_endpoint":
   "https://server.example.com/userinfo",
 "jwks_uri":
   "https://server.example.com/jwks.json",
 "registration_endpoint":
   "https://server.example.com/register",
 "scopes_supported":
   ["openid", "profile", "email", "address",
    "phone", "offline_access"],
 "response_types_supported":
   ["code", "code token"],
 "service_documentation":
   "http://server.example.com/service_documentation.html",
 "ui_locales_supported":
   ["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
}

3.3. Authorization Server Metadata Validation (Validazione dei metadati del server di autorizzazione)​

Il valore "issuer" restituito deve (MUST) essere esattamente identico al valore dell'identificatore dell'emittente del server di autorizzazione in cui è stata inserita la stringa URI nota per creare l'URL utilizzato per recuperare i metadati. Se questi valori non sono esattamente identici, i dati contenuti nella risposta non devono (MUST NOT) essere utilizzati.

Ultimo aggiornamento il