2. Registrazione del client (Client Registration)
Prima di avviare il protocollo, il client si registra presso il server di autorizzazione (Authorization Server). Il modo in cui il client si registra presso il server di autorizzazione va oltre l'ambito di questa specifica, ma tipicamente coinvolge l'interazione dell'utente finale con un modulo di registrazione HTML.
La registrazione del client non richiede (MUST NOT) un'interazione diretta tra il client e il server di autorizzazione. Quando supportata dal server di autorizzazione, la registrazione può fare affidamento su altri mezzi per stabilire una relazione di fiducia e ottenere le proprietà del client (come l'URI di reindirizzamento, il tipo di client). Ad esempio, la registrazione può essere completata utilizzando asserzioni auto-emesse o emesse da terzi, o mediante il server di autorizzazione che esegue la scoperta del client utilizzando un canale affidabile.
Durante la registrazione di un client, lo sviluppatore del client dovrebbe (SHOULD):
- Specificare il tipo di client come descritto nella sezione 2.1
- Fornire il proprio URI di reindirizzamento come descritto nella sezione 3.1.2
- Includere qualsiasi altra informazione richiesta dal server di autorizzazione (ad esempio, nome dell'applicazione, sito web, descrizione, immagine del logo, accettazione dei termini legali)
2.1. Tipi di client (Client Types)
In base alla capacità del client di autenticarsi in modo sicuro presso il server di autorizzazione (cioè la capacità di mantenere la riservatezza delle proprie credenziali), OAuth definisce due tipi di client:
Client confidenziale (Confidential Client)
Un client capace di mantenere la riservatezza delle proprie credenziali (ad esempio, il client viene eseguito su un server sicuro con accesso limitato alle credenziali del client) o capace di garantire l'autenticazione sicura del client attraverso altri mezzi.
Client pubblico (Public Client)
Un client incapace di mantenere la riservatezza delle proprie credenziali (ad esempio, il client viene eseguito sul dispositivo utilizzato dal proprietario della risorsa, come un'applicazione nativa installata o un'applicazione basata su browser web) e incapace di garantire l'autenticazione sicura del client attraverso altri mezzi.
La scelta del tipo di client si basa sulle definizioni di autenticazione di sicurezza del server di autorizzazione e sul suo livello di esposizione accettabile delle credenziali del client. Il server di autorizzazione non dovrebbe (SHOULD NOT) fare ipotesi sul tipo di client.
Un client può essere implementato come un insieme di componenti distribuiti, ciascuno con un tipo di client e un contesto di sicurezza diverso (ad esempio, un client distribuito con sia un componente confidenziale basato su server che un componente pubblico basato su browser). Se il server di autorizzazione non supporta tali client o non fornisce indicazioni riguardo alla loro registrazione, il client dovrebbe (SHOULD) registrare ogni componente separatamente come client distinto.
Questa specifica è stata progettata attorno ai seguenti profili di client:
Applicazione web (Web Application)
Un'applicazione web è un client confidenziale in esecuzione su un server web. Il proprietario della risorsa accede al client tramite un'interfaccia utente HTML renderizzata in un user agent sul dispositivo utilizzato dal proprietario della risorsa. Le credenziali del client e tutti i token di accesso emessi al client vengono memorizzati sul server web e non sono esposti o accessibili al proprietario della risorsa.
Applicazione basata su user agent (User-Agent-Based Application)
Un'applicazione basata su user agent è un client pubblico in cui il codice del client viene scaricato da un server web ed eseguito in un user agent (ad esempio, un browser web) sul dispositivo utilizzato dal proprietario della risorsa. I dati del protocollo e le credenziali sono facilmente accessibili (e spesso visibili) al proprietario della risorsa. Poiché queste applicazioni risiedono nell'user agent, possono utilizzare senza problemi le capacità dell'user agent quando richiedono l'autorizzazione.
Applicazione nativa (Native Application)
Un'applicazione nativa è un client pubblico installato ed eseguito sul dispositivo utilizzato dal proprietario della risorsa. I dati del protocollo e le credenziali sono accessibili al proprietario della risorsa. Si presume che qualsiasi credenziale di autenticazione del client inclusa nell'applicazione possa essere estratta. D'altra parte, le credenziali emesse dinamicamente come i token di accesso o i token di aggiornamento (Refresh Token) possono raggiungere un livello di protezione accettabile. Come minimo, queste credenziali sono protette da server malevoli con cui l'applicazione può interagire. Su alcune piattaforme, queste credenziali possono essere protette da altre applicazioni che risiedono sullo stesso dispositivo.
2.2. Identificatore del client (Client Identifier)
Il server di autorizzazione emette a un client registrato un identificatore del client (Client Identifier) — una stringa univoca che rappresenta le informazioni di registrazione fornite dal client. L'identificatore del client non è un segreto; è esposto al proprietario della risorsa e non deve (MUST NOT) essere utilizzato da solo per l'autenticazione del client. L'identificatore del client è univoco per il server di autorizzazione.
La dimensione della stringa dell'identificatore del client non è definita da questa specifica. Il client dovrebbe (SHOULD) evitare di fare ipotesi sulla dimensione dell'identificatore. Il server di autorizzazione dovrebbe (SHOULD) documentare la dimensione di qualsiasi identificatore che emette.
2.3. Autenticazione del client (Client Authentication)
Se il tipo di client è confidenziale, il client e il server di autorizzazione stabiliscono un metodo di autenticazione del client appropriato ai requisiti di sicurezza del server di autorizzazione. Il server di autorizzazione può (MAY) accettare qualsiasi forma di autenticazione del client che soddisfi i suoi requisiti di sicurezza.
I client confidenziali ricevono tipicamente (o stabiliscono) un insieme di credenziali del client da utilizzare per l'autenticazione presso il server di autorizzazione (ad esempio, password, coppia di chiavi pubblica/privata). Il server di autorizzazione può (MAY) stabilire un metodo di autenticazione del client con i client pubblici. Tuttavia, il server di autorizzazione non deve (MUST NOT) fare affidamento sull'autenticazione del client pubblico per identificare il client.
Il client non deve (MUST NOT) utilizzare più di un metodo di autenticazione in ogni richiesta.
2.3.1. Password del client (Client Password)
I client con una password del client possono (MAY) utilizzare lo schema di autenticazione HTTP Basic definito in <RFC2617> per autenticarsi presso il server di autorizzazione. L'identificatore del client viene codificato utilizzando l'algoritmo di codifica application/x-www-form-urlencoded definito nell'Appendice B, e il valore codificato viene utilizzato come nome utente; la password del client viene codificata utilizzando lo stesso algoritmo e utilizzata come password. Il server di autorizzazione deve (MUST) supportare lo schema di autenticazione HTTP Basic per l'autenticazione dei client con password del client emessa.
Ad esempio (interruzioni di riga aggiuntive solo per scopi di visualizzazione):
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
In alternativa, il server di autorizzazione può (MAY) supportare l'inclusione delle credenziali del client nel corpo della richiesta utilizzando i seguenti parametri:
client_id
Richiesto (REQUIRED). L'identificatore del client emesso al client durante il processo di registrazione descritto nella sezione 2.2.
client_secret
Richiesto (REQUIRED). Il segreto del client. Il client può (MAY) omettere questo parametro se il segreto del client è una stringa vuota.
L'inclusione delle credenziali del client nel corpo della richiesta utilizzando questi due parametri non è raccomandato (NOT RECOMMENDED) e dovrebbe (SHOULD) essere limitato ai client incapaci di utilizzare direttamente lo schema di autenticazione HTTP Basic (o un altro schema di autenticazione HTTP basato su password). I parametri devono essere trasmessi solo nel corpo della richiesta e non devono (MUST NOT) essere inclusi nell'URI della richiesta.
Il server di autorizzazione deve (MUST) richiedere l'uso di TLS come descritto nella sezione 1.6 quando si inviano richieste utilizzando l'autenticazione tramite password.
Poiché questo metodo di autenticazione del client comporta una password, il server di autorizzazione deve (MUST) proteggere tutti gli endpoint che utilizzano questa password da attacchi di forza bruta.
2.3.2. Altri metodi di autenticazione (Other Authentication Methods)
Il server di autorizzazione può (MAY) supportare qualsiasi schema di autenticazione HTTP appropriato che soddisfi i suoi requisiti di sicurezza. Quando si utilizzano altri metodi di autenticazione, il server di autorizzazione deve (MUST) definire una mappatura tra l'identificatore del client (la registrazione) e lo schema di autenticazione.
2.4. Client non registrati (Unregistered Clients)
Questa specifica non prevede l'uso di client non registrati. Tuttavia, il server di autorizzazione può (MAY) supportare tali client.
Quando si utilizzano client non registrati, l'identificatore del client viene ottenuto in un altro modo non definito da questa specifica. Il server di autorizzazione dovrebbe (SHOULD) documentare i requisiti e le restrizioni relative all'uso di client non registrati.