3. Endpoint del protocollo (Protocol Endpoints)
Il processo di autorizzazione utilizza due endpoint del server di autorizzazione (endpoint HTTP):
- Endpoint di autorizzazione (Authorization Endpoint) - Utilizzato dal client per ottenere l'autorizzazione dal proprietario della risorsa tramite il reindirizzamento dell'user agent.
- Endpoint del token (Token Endpoint) - Utilizzato dal client per scambiare un'autorizzazione (Authorization Grant) o un token di aggiornamento (Refresh Token) con un token di accesso (Access Token).
Inoltre, esiste un endpoint del client (Client Endpoint):
- Endpoint di reindirizzamento (Redirection Endpoint) - Utilizzato dal server di autorizzazione per restituire risposte contenenti informazioni di autorizzazione al client tramite l'user agent del proprietario della risorsa.
Non tutti gli endpoint vengono utilizzati in tutti i flussi di autorizzazione OAuth. Ad esempio, il flusso implicito (Implicit Grant) non utilizza l'endpoint del token, mentre il flusso delle credenziali password del proprietario della risorsa (Resource Owner Password Credentials Grant) non utilizza l'endpoint di autorizzazione.
Gli URI degli endpoint possono (MAY) includere un componente di query (<RFC3986> Sezione 3), ma non devono (MUST NOT) contenere un componente di frammento. Il server di autorizzazione e il client devono (MUST) aggiungere parametri aggiuntivi agli URI contenenti i parametri definiti da questa specifica utilizzando il componente di query o il formato application/x-www-form-urlencoded. Tuttavia, l'URI di reindirizzamento è esente da questo requisito.
3.1. Endpoint di autorizzazione (Authorization Endpoint)
L'endpoint di autorizzazione (Authorization Endpoint) viene utilizzato per interagire con il proprietario della risorsa e ottenere l'autorizzazione. Il server di autorizzazione deve (MUST) prima verificare l'identità del proprietario della risorsa. Il modo in cui il server di autorizzazione autentica il proprietario della risorsa (ad esempio, nome utente e password, cookie di sessione) va oltre l'ambito di questa specifica.
I mezzi attraverso i quali il client ottiene l'autorizzazione dal proprietario della risorsa (tramite reindirizzamento o direttamente) devono essere determinati secondo le capacità, i requisiti e le considerazioni di sicurezza del server di autorizzazione. Quando si utilizza un flusso basato su reindirizzamento, il server di autorizzazione agisce come intermediario tra il client e il proprietario della risorsa tramite l'user agent (tipicamente un browser web).
Quando si comunica con l'endpoint di autorizzazione tramite reindirizzamento HTTP, il server di autorizzazione deve (MUST) richiedere l'uso di TLS. L'URI dell'endpoint deve (MUST) essere un URI assoluto come definito da <RFC2616>. L'URI dell'endpoint non deve (MUST NOT) includere un componente di frammento.
Poiché l'endpoint di autorizzazione non richiede l'autenticazione del client, può essere vulnerabile ad alcune falle di sicurezza come:
- Il proprietario della risorsa non può autenticare il client e può essere ingannato da un client malevolo.
- Il proprietario della risorsa non può autenticare il server di autorizzazione e può essere ingannato da un server di autorizzazione malevolo.
Per mitigare queste minacce, il server di autorizzazione dovrebbe (SHOULD) consentire al proprietario della risorsa di verificare l'identità del client (vedere Sezione 10.12) e utilizzare TLS per garantire l'autenticità dell'endpoint del server di autorizzazione (vedere Sezioni 1.6 e 10.9).
3.1.1. Tipo di risposta (Response Type)
L'endpoint di autorizzazione (Authorization Endpoint) viene utilizzato per supportare più tipi di risposta, determinati dal parametro di richiesta response_type. Il valore del parametro response_type è un elenco sensibile alle maiuscole/minuscole delimitato da spazi che utilizza solo caratteri ASCII [USASCII].
I tipi di risposta di estensione possono (MAY) contenere valori aggiuntivi. Se il parametro response_type contiene un valore non riconosciuto o manca un valore, il server di autorizzazione deve (MUST) restituire una risposta di errore come descritto nella Sezione 4.1.2.1.
3.1.2. Endpoint di reindirizzamento (Redirection Endpoint)
Dopo aver completato la sua interazione con il proprietario della risorsa, il server di autorizzazione reindirizza l'user agent del proprietario della risorsa al client. Il server di autorizzazione reindirizza l'user agent del proprietario della risorsa all'URI di reindirizzamento (Redirection URI) registrato del client.
L'URI dell'endpoint di reindirizzamento deve (MUST) soddisfare i seguenti requisiti:
- Deve (MUST) essere un URI assoluto come definito da
<RFC3986>Sezione 4.3. - L'URI di reindirizzamento non deve (MUST NOT) includere un componente di frammento.
Riservatezza delle richieste dell'endpoint
L'endpoint di reindirizzamento (Redirection Endpoint) dovrebbe (SHOULD) richiedere l'uso di TLS quando le informazioni richieste o scambiate sono sensibili o di valore. Le credenziali del client e i token di accesso possono essere inclusi nella risposta durante il reindirizzamento, quindi è consigliabile utilizzare TLS (vedere Sezioni 1.6 e 10.9).
Requisiti di registrazione
Il server di autorizzazione deve (MUST) richiedere la registrazione dell'URI di reindirizzamento per:
- Client pubblici (Public Client)
- Client confidenziali (Confidential Client) che utilizzano il tipo di autorizzazione implicita (Implicit Grant Type)
Il server di autorizzazione dovrebbe (SHOULD) richiedere la registrazione dell'URI di reindirizzamento per tutti i client.
Il server di autorizzazione dovrebbe (SHOULD) consentire al client di registrare più URI di reindirizzamento. Non presupporre che una parte degli URI di reindirizzamento registrati non corrisponderà.
Quando è richiesta la registrazione dell'URI di reindirizzamento, il server di autorizzazione dovrebbe (SHOULD) consentire la registrazione di URI di reindirizzamento parziali. In questo caso, il server di autorizzazione deve (MUST) validare l'URI di reindirizzamento completo fornito dal client ad ogni richiesta (vedere Sezione 3.1.2.3).
Configurazione dinamica
Se nessun URI di reindirizzamento è registrato, il client deve (MUST) includere un URI di reindirizzamento in ogni richiesta di autorizzazione (utilizzando il parametro redirect_uri).
Se un URI di reindirizzamento è registrato e nessun URI di reindirizzamento è incluso nella richiesta di autorizzazione, il server di autorizzazione deve (MUST) utilizzare l'URI di reindirizzamento registrato.
Se un URI di reindirizzamento è incluso nella richiesta di autorizzazione, il server di autorizzazione deve (MUST) verificare che il valore richiesto corrisponda ad almeno uno degli URI di reindirizzamento registrati.
Endpoint non valido
Se si verifica un errore durante la validazione dell'URI di reindirizzamento, il server di autorizzazione deve (MUST) informare il proprietario della risorsa e non deve (MUST NOT) reindirizzare automaticamente all'URI di reindirizzamento non valido.
Contenuto dell'endpoint
La richiesta di reindirizzamento può contenere informazioni sensibili come il codice di autorizzazione (Authorization Code) o il token di accesso (Access Token), quindi il client dovrebbe (SHOULD) assicurarsi che l'endpoint di reindirizzamento non divulghi informazioni a terze parti (diverse dal proprietario della risorsa).
3.2. Endpoint del token (Token Endpoint)
L'endpoint del token (Token Endpoint) viene utilizzato dal client per ottenere un token di accesso (Access Token) presentando un'autorizzazione (Authorization Grant) o un token di aggiornamento (Refresh Token). L'endpoint del token viene utilizzato con tutti i tipi di autorizzazione tranne il tipo di autorizzazione implicita (Implicit Grant Type) (dove un token di accesso viene emesso direttamente dall'endpoint di autorizzazione).
La posizione dell'endpoint del token e il modo per accedervi sono tipicamente descritti nella documentazione del servizio. L'URI dell'endpoint può (MAY) includere un componente di query (<RFC3986> Sezione 3), ma non deve (MUST NOT) contenere parametri aggiuntivi. L'URI dell'endpoint non deve (MUST NOT) includere un componente di frammento.
L'endpoint del token deve (MUST) richiedere l'uso di TLS. Il client deve (MUST) utilizzare il metodo HTTP POST per effettuare richieste all'endpoint del token.
I parametri inclusi nelle richieste all'endpoint del token devono (MUST) essere inviati nel corpo dell'entità della richiesta HTTP e devono (MUST) utilizzare il formato application/x-www-form-urlencoded.
3.2.1. Autenticazione del client (Client Authentication)
I client confidenziali (Confidential Client) o altri client che hanno ricevuto credenziali del client devono (MUST) autenticarsi presso il server di autorizzazione all'endpoint del token. L'autenticazione del client viene utilizzata per i seguenti scopi:
- Confermare l'identità del client (basata solo sull'identificatore del client). Questo è importante per impedire ai client confidenziali di scambiare un codice di autorizzazione non autorizzato con un token di accesso. Quando la trasmissione del codice di autorizzazione avviene su un canale non sicuro, o quando il server di autorizzazione non può confermare che il client ha ottenuto il codice di autorizzazione, il server di autorizzazione deve (MUST) imporre l'autenticazione del client.
- Legare i token di aggiornamento (Refresh Token) al client. Quando il token di aggiornamento è legato al client, l'autenticazione del client impedisce a un altro client di abusare di un token di aggiornamento compromesso.
- Consentire al client di ruotare le proprie credenziali del client.
Il client non deve (MUST NOT) utilizzare più di un metodo di autenticazione in ogni richiesta. I client pubblici (Public Client) (client senza credenziali del client) devono (MUST) includere l'identificatore del client nelle richieste inviate all'endpoint del token.
3.3. Ambito del token di accesso (Access Token Scope)
Gli endpoint di autorizzazione e del token consentono al client di specificare l'ambito (Scope) della richiesta di accesso utilizzando il parametro di richiesta scope. Il server di autorizzazione informa quindi il client dell'ambito del token di accesso emesso utilizzando il parametro di risposta scope.
Il valore del parametro scope è espresso come un elenco di valori di ambito delimitati da spazi, sensibili alle maiuscole/minuscole. La definizione dei valori di ambito è lasciata al server di autorizzazione. Se i valori di ambito sono definiti, il server di autorizzazione deve (MUST) documentare sia gli ambiti richiesti dal client che gli ambiti effettivamente concessi.
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
Il server di autorizzazione può (MAY) documentare completamente i valori di ambito supportati. Il server di autorizzazione può (MAY) approvare parzialmente, rifiutare o ignorare qualsiasi o tutti gli ambiti richiesti dal client. Se la richiesta non include il parametro scope o è vuoto, il server di autorizzazione deve (MUST) rifiutare la richiesta di autorizzazione, applicare un ambito predefinito o ignorare l'ambito richiesto dal client. Il server di autorizzazione non deve (MUST NOT) rispondere con un ambito vuoto.