1. Introduzione

Affinché un client OAuth 2.0 [RFC6749] possa utilizzare un server di autorizzazione OAuth 2.0, il client necessita di informazioni specifiche per interagire con il server, incluso un identificatore client OAuth 2.0 da utilizzare presso quel server. Questa specifica descrive come un client OAuth 2.0 possa essere registrato dinamicamente presso un server di autorizzazione per ottenere queste informazioni.

Come parte del processo di registrazione, questa specifica definisce anche un meccanismo per il client per presentare al server di autorizzazione un insieme di metadati, come un insieme di URI di reindirizzamento validi. Questi metadati possono essere comunicati in modo auto-dichiarato o come un insieme di metadati chiamato dichiarazione software (software statement), che è firmato digitalmente o protetto con un Codice di Autenticazione del Messaggio (MAC); nel caso di una dichiarazione software, l'emittente garantisce la validità dei dati riguardanti il client.

Tradizionalmente, la registrazione di un client presso un server di autorizzazione viene eseguita manualmente. I meccanismi definiti in questa specifica possono essere utilizzati sia da un client per registrarsi dinamicamente presso i server di autorizzazione sia da uno sviluppatore client per registrare programmaticamente il client presso i server di autorizzazione. Molteplici applicazioni che utilizzano OAuth 2.0 hanno precedentemente sviluppato meccanismi per compiere tali registrazioni. Questa specifica generalizza i meccanismi di registrazione definiti da "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] e utilizzati da "User Managed Access (UMA) Profile of OAuth 2.0" [UMA-Core] in un modo che è compatibile con entrambi, pur essendo applicabile a un insieme più ampio di casi d'uso OAuth 2.0.

1.1. Convenzioni di Notazione

Le parole chiave 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY' e 'OPTIONAL' in questo documento devono essere interpretate come descritto in [RFC2119].

Se non diversamente indicato, tutti i nomi e i valori dei parametri del protocollo fanno distinzione tra maiuscole e minuscole.

1.2. Terminologia

Questa specifica utilizza i termini "token di accesso", "codice di autorizzazione", "endpoint di autorizzazione", "concessione di autorizzazione", "server di autorizzazione", "client", "identificatore client", "segreto client", "tipo di concessione", "risorsa protetta", "URI di reindirizzamento", "token di aggiornamento", "proprietario della risorsa", "server delle risorse", "tipo di risposta" e "endpoint di token" definiti da OAuth 2.0 [RFC6749] e utilizza il termine "Claim" definito da JSON Web Token (JWT) [RFC7519].

Questa specifica definisce i seguenti termini:

Client Software (Software Client) Software che implementa un client OAuth 2.0.

Client Instance (Istanza Client) Un'istanza distribuita di un pezzo di software client.

Client Developer (Sviluppatore Client) La persona o l'organizzazione che costruisce un pacchetto software client e lo prepara per la distribuzione. Al momento in cui il client viene costruito, lo sviluppatore spesso non è a conoscenza di chi saranno le organizzazioni fornitrici di servizi che distribuiranno il software. Gli sviluppatori client dovranno utilizzare la registrazione dinamica quando non sono in grado di prevedere aspetti del software, come gli URL di distribuzione, al momento della compilazione. Ad esempio, ciò può verificarsi quando l'editore dell'API software e l'organizzazione di distribuzione non sono gli stessi.

Client Registration Endpoint (Endpoint di Registrazione Client) Endpoint OAuth 2.0 attraverso il quale un client può essere registrato presso un server di autorizzazione. I mezzi con cui l'URL per questo endpoint viene ottenuto sono fuori dallo scopo di questa specifica.

Initial Access Token (Token di Accesso Iniziale) Token di accesso OAuth 2.0 emesso opzionalmente da un server di autorizzazione a uno sviluppatore o client e utilizzato per autorizzare le chiamate all'endpoint di registrazione client. Il tipo e il formato di questo token sono probabilmente specifici del servizio e fuori dallo scopo di questa specifica. I mezzi con cui il server di autorizzazione emette questo token così come i mezzi con cui l'endpoint di registrazione convalida questo token sono fuori dallo scopo di questa specifica. L'uso di un token di accesso iniziale è richiesto quando il server di autorizzazione limita le parti che possono registrare un client.

Deployment Organization (Organizzazione di Distribuzione) Un dominio di sicurezza amministrativo sotto il quale un'API software (servizio) è distribuita e protetta da un framework OAuth 2.0. In alcuni scenari OAuth, l'organizzazione di distribuzione e l'editore dell'API software sono gli stessi. In questi casi, l'organizzazione di distribuzione avrà spesso una stretta relazione con gli sviluppatori di software client. In molti altri casi, il definitore del servizio può essere un editore di terze parti indipendente o un'organizzazione di standardizzazione. Quando si lavora su una specifica pubblicata per un'API, lo sviluppatore di software client non è in grado di avere una relazione precedente con le potenzialmente numerose organizzazioni di distribuzione che distribuiscono l'API software (servizio).

Software API Deployment (Distribuzione API Software) Un'istanza distribuita di un'API software che è protetta da OAuth 2.0 (una risorsa protetta) in un particolare dominio dell'organizzazione di distribuzione. Per qualsiasi particolare API software, ci possono essere una o più distribuzioni. Una distribuzione di API software ha tipicamente un server di autorizzazione OAuth 2.0 associato così come un endpoint di registrazione client. I mezzi con cui gli endpoint vengono ottenuti sono fuori dallo scopo di questa specifica.

Software API Publisher (Editore API Software) L'organizzazione che definisce una particolare API accessibile via web che può essere distribuita in uno o più ambienti di distribuzione. Un editore può essere qualsiasi organismo di standardizzazione, commerciale, pubblico, privato o organizzazione open source che è responsabile della pubblicazione e distribuzione di software e specifiche API che possono essere protette tramite OAuth 2.0. In alcuni casi, un editore di API software e uno sviluppatore client possono essere la stessa organizzazione. Al momento della pubblicazione di un'API accessibile via web, l'editore del software spesso non ha una relazione precedente con le organizzazioni di distribuzione.

Software Statement (Dichiarazione Software) Un JSON Web Token (JWT) [RFC7519] firmato digitalmente o MACato che asserisce valori di metadati riguardanti il software client. In alcuni casi, una dichiarazione software sarà emessa direttamente dallo sviluppatore client. In altri casi, una dichiarazione software sarà emessa da un'organizzazione di terze parti per l'uso da parte dello sviluppatore client. In entrambi i casi, la relazione di fiducia che il server di autorizzazione ha con l'emittente della dichiarazione software è destinata ad essere utilizzata come input per la valutazione se la richiesta di registrazione viene accettata. Una dichiarazione software può essere presentata a un server di autorizzazione come parte di una richiesta di registrazione client.

1.3. Flusso del Protocollo

    +--------(A)- Token di Accesso Iniziale (OPZIONALE)
    |
    |   +----(B)- Dichiarazione Software (OPZIONALE)
    |   |
    v   v
+-----------+                                      +---------------+
|           |--(C)- Richiesta Registrazione Client -->|    Client     |
| Client o  |                                      | Registrazione |
| Sviluppatore|<-(D)- Risposta Informazioni Client ---|    Endpoint   |
|           |        o Risposta Errore Client      +---------------+
+-----------+

Figura 1: Flusso Astratto di Registrazione Dinamica Client

Il flusso astratto di registrazione dinamica client OAuth 2.0 illustrato nella Figura 1 descrive l'interazione tra il client o lo sviluppatore e l'endpoint definito in questa specifica. Questa figura non dimostra le condizioni di errore. Questo flusso include i seguenti passaggi:

(A) Opzionalmente, al client o allo sviluppatore viene emesso un token di accesso iniziale che dà accesso all'endpoint di registrazione client. Il metodo con cui il token di accesso iniziale viene emesso al client o allo sviluppatore è fuori dallo scopo di questa specifica.

(B) Opzionalmente, al client o allo sviluppatore viene emessa una dichiarazione software per l'uso con l'endpoint di registrazione client. Il metodo con cui la dichiarazione software viene emessa al client o allo sviluppatore è fuori dallo scopo di questa specifica.

(C) Il client o lo sviluppatore chiama l'endpoint di registrazione client con i metadati di registrazione desiderati dal client, includendo opzionalmente il token di accesso iniziale da (A) se ne è richiesto uno dal server di autorizzazione.

(D) Il server di autorizzazione registra il client e restituisce:

  *  i metadati registrati del client,

  *  un identificatore client che è unico presso il server, e

  *  un insieme di credenziali client come un segreto client, se applicabile per questo client.

Esempi di diverse configurazioni e utilizzi sono inclusi nell'Appendice A.