11. Autenticazione HTTP (HTTP Authentication)
11.1. Schema di Autenticazione (Authentication Scheme)
HTTP fornisce un framework generale per il controllo degli accessi e l'autenticazione attraverso un insieme estensibile di schemi di autenticazione challenge-response, che un server può utilizzare per sfidare una richiesta client e che un client può utilizzare per fornire informazioni di autenticazione. Utilizza un token insensibile alle maiuscole/minuscole per identificare lo schema di autenticazione:
auth-scheme = token
A parte il framework generale, questo documento non specifica alcuno schema di autenticazione. Gli schemi di autenticazione nuovi ed esistenti sono specificati indipendentemente e dovrebbero essere registrati nel "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry". Ad esempio, gli schemi di autenticazione "basic" e "digest" sono definiti rispettivamente da [RFC7617] e [RFC7616].
11.2. Parametri di Autenticazione (Authentication Parameters)
Uno schema di autenticazione è seguito da informazioni aggiuntive necessarie per eseguire l'autenticazione tramite quello schema, sotto forma di elenco di parametri separati da virgole o di una singola sequenza di caratteri in grado di contenere informazioni codificate in base64.
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
La sintassi token68 consente i 66 caratteri URI non riservati ([URI]), più alcuni altri, in modo che possa contenere una codifica base64, base64url (alfabeto sicuro per URL e nomi di file), base32 o base16 (esadecimale), con o senza padding, ma escludendo gli spazi bianchi ([RFC4648]).
I parametri di autenticazione sono coppie nome/valore, dove il token del nome viene confrontato senza distinzione tra maiuscole e minuscole, e ogni nome di parametro può apparire una sola volta per challenge.
auth-param = token BWS "=" BWS ( token / quoted-string )
I valori dei parametri possono essere espressi come "token" o come "quoted-string" (Sezione 5.6). Le definizioni degli schemi di autenticazione devono accettare entrambe le notazioni, sia per i mittenti che per i destinatari, per consentire ai destinatari di utilizzare componenti di parsing generici indipendentemente dallo schema di autenticazione.
Per retrocompatibilità, le definizioni degli schemi di autenticazione possono limitare il formato per i mittenti a una delle due varianti. Questo può essere importante quando è noto che le implementazioni distribuite falliranno quando incontrano uno dei due formati.
11.3. Challenge e Response (Challenge and Response)
Un server di origine utilizza il messaggio di risposta 401 (Unauthorized) per sfidare l'autorizzazione di un user agent, includendo un campo di intestazione WWW-Authenticate contenente almeno una challenge applicabile alla risorsa richiesta.
Un proxy utilizza il messaggio di risposta 407 (Proxy Authentication Required) per sfidare l'autorizzazione di un client, includendo un campo di intestazione Proxy-Authenticate contenente almeno una challenge applicabile al proxy per la risorsa richiesta.
challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Nota: Molti client non riescono ad analizzare una challenge contenente uno schema sconosciuto. Una soluzione a questo problema consiste nell'elencare prima gli schemi ben supportati (come "basic").
Un user agent che desidera autenticarsi presso un server di origine -- solitamente, ma non necessariamente, dopo aver ricevuto un 401 (Unauthorized) -- può farlo includendo un campo di intestazione Authorization con la richiesta.
Un client che desidera autenticarsi presso un proxy -- solitamente, ma non necessariamente, dopo aver ricevuto un 407 (Proxy Authentication Required) -- può farlo includendo un campo di intestazione Proxy-Authorization con la richiesta.
11.4. Credenziali (Credentials)
Il valore del campo Authorization e il valore del campo Proxy-Authorization contengono entrambi le credenziali del client per il realm della risorsa richiesta, basate su una challenge ricevuta in una risposta (possibilmente in un momento nel passato). Nel creare i loro valori, lo user agent dovrebbe farlo selezionando la challenge con quello che considera l'auth-scheme più sicuro che comprende, ottenendo le credenziali dall'utente in modo appropriato. La trasmissione di credenziali nei valori dei campi di intestazione implica considerazioni di sicurezza significative riguardanti la riservatezza della connessione sottostante, come descritto nella Sezione 17.16.1.
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Alla ricezione di una richiesta per una risorsa protetta che omette le credenziali, contiene credenziali non valide (ad esempio, una password errata) o credenziali parziali (ad esempio, quando lo schema di autenticazione richiede più di un round-trip), un server di origine DOVREBBE (SHOULD) inviare una risposta 401 (Unauthorized) che contiene un campo di intestazione WWW-Authenticate con almeno una challenge (possibilmente nuova) applicabile alla risorsa richiesta.
Allo stesso modo, alla ricezione di una richiesta che omette le credenziali del proxy o contiene credenziali del proxy non valide o parziali, un proxy che richiede l'autenticazione DOVREBBE (SHOULD) generare una risposta 407 (Proxy Authentication Required) che contiene un campo di intestazione Proxy-Authenticate con almeno una challenge (possibilmente nuova) applicabile al proxy.
Un server che riceve credenziali valide ma inadeguate per ottenere l'accesso dovrebbe rispondere con il codice di stato 403 (Forbidden) (Sezione 15.5.4).
HTTP non limita le applicazioni a questo semplice framework challenge-response per l'autenticazione di accesso. Possono essere utilizzati meccanismi aggiuntivi, come l'autenticazione a livello di trasporto o tramite l'incapsulamento dei messaggi, e con campi di intestazione aggiuntivi che specificano le informazioni di autenticazione. Tuttavia, tali meccanismi aggiuntivi non sono definiti da questa specifica.
Si noti che vari meccanismi di autenticazione utente personalizzati sono implementati utilizzando i campi di intestazione Set-Cookie e Cookie, definiti in [COOKIE], per trasportare token relativi all'autenticazione.
11.5. Stabilire uno Spazio di Protezione (Realm) (Establishing a Protection Space (Realm))
Il parametro di autenticazione "realm" è riservato per l'uso da parte degli schemi di autenticazione che desiderano indicare un ambito di protezione.
Uno spazio di protezione è definito dall'origine (vedi Sezione 4.3.1) del server a cui si accede, in combinazione con il valore realm se presente. Questi realm consentono di partizionare le risorse protette su un server in un insieme di spazi di protezione, ciascuno con il proprio schema di autenticazione e/o database di autorizzazione. Il valore realm è una stringa, generalmente assegnata dal server di origine, che può avere una semantica aggiuntiva specifica dello schema di autenticazione. Si noti che una risposta può avere più challenge con lo stesso auth-scheme ma realm diversi.
Lo spazio di protezione determina il dominio su cui le credenziali possono essere applicate automaticamente. Se una richiesta precedente è stata autorizzata, lo user agent PUÒ (MAY) riutilizzare le stesse credenziali per tutte le altre richieste all'interno di quello spazio di protezione per un periodo di tempo determinato dallo schema di autenticazione, dai parametri e/o dalle preferenze dell'utente (come un timeout di inattività configurabile).
L'estensione di uno spazio di protezione, e quindi dove le credenziali potrebbero essere applicate automaticamente da un client, non è necessariamente nota al client a meno che non ci siano informazioni aggiuntive. Gli schemi di autenticazione possono definire parametri che descrivono l'estensione di uno spazio di protezione. Uno spazio di protezione non può estendersi oltre l'ambito del suo server a meno che non sia specificamente consentito dallo schema di autenticazione.
Per ragioni storiche, un mittente DEVE (MUST) generare solo la sintassi quoted-string. I destinatari potrebbero dover supportare sia la sintassi token che quoted-string per la massima interoperabilità con i client esistenti che hanno accettato entrambe le notazioni da tempo.
11.6. Autenticazione degli Utenti ai Server di Origine (Authenticating Users to Origin Servers)
11.6.1. WWW-Authenticate
Il campo di intestazione di risposta "WWW-Authenticate" indica lo schema o gli schemi di autenticazione e i parametri applicabili alla risorsa di destinazione.
WWW-Authenticate = #challenge
Un server che genera una risposta 401 (Unauthorized) DEVE (MUST) inviare un campo di intestazione WWW-Authenticate contenente almeno una challenge. Un server PUÒ (MAY) generare un campo di intestazione WWW-Authenticate in altri messaggi di risposta per indicare che fornire credenziali (o credenziali diverse) potrebbe influenzare la risposta.
Un proxy che inoltra una risposta NON DEVE (MUST NOT) modificare alcun campo di intestazione WWW-Authenticate in quella risposta.
Si consiglia agli user agent di prestare particolare attenzione nell'analisi del valore del campo, poiché può contenere più di una challenge, e ogni challenge può contenere un elenco separato da virgole di parametri di autenticazione. Inoltre, il campo di intestazione stesso può apparire più volte.
Ad esempio:
WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
type=1, title="Login to \"apps\""
Questo campo di intestazione contiene due challenge, una per lo schema "Basic" con un valore realm di "simple", e un'altra per lo schema "Newauth" con un valore realm di "apps". Contiene anche due parametri aggiuntivi, "type" e "title".
Tuttavia, alcuni user agent non riconoscono questa forma. Pertanto, l'invio di un valore di campo WWW-Authenticate con più membri sulla stessa riga di campo potrebbe non essere interoperabile.
Nota: Anche la produzione grammaticale della challenge utilizza la sintassi dell'elenco. Pertanto, una sequenza di virgola, spazio bianco e virgola può essere considerata come applicabile alla challenge precedente, o come una voce vuota nell'elenco delle challenge. In pratica, questa ambiguità non influisce sulla semantica del valore del campo di intestazione ed è quindi innocua.
11.6.2. Authorization
Il campo di intestazione "Authorization" consente a uno user agent di autenticarsi presso un server di origine -- solitamente, ma non necessariamente, dopo aver ricevuto una risposta 401 (Unauthorized). Il suo valore consiste in credenziali contenenti le informazioni di autenticazione dello user agent per il realm della risorsa richiesta.
Authorization = credentials
Se una richiesta è autenticata e viene specificato un realm, si presume che le stesse credenziali siano valide per tutte le altre richieste all'interno di quel realm (supponendo che lo schema di autenticazione stesso non richieda altrimenti, come credenziali che variano in base a un valore di challenge o l'uso di orologi sincronizzati).
Un proxy che inoltra una richiesta NON DEVE (MUST NOT) modificare alcun campo di intestazione Authorization in quella richiesta. Vedere la Sezione 3.5 di [CACHING] per i dettagli e i requisiti relativi alla gestione del campo di intestazione Authorization da parte delle cache HTTP.
11.6.3. Authentication-Info
Gli schemi di autenticazione HTTP possono utilizzare il campo di risposta "Authentication-Info" per comunicare informazioni dopo che le credenziali di autenticazione del client sono state accettate. Queste informazioni possono includere un messaggio finale dal server (ad esempio, possono contenere l'autenticazione del server).
Il valore del campo è un elenco di parametri (coppie nome/valore), utilizzando la sintassi "auth-param" definita nella Sezione 11.3. Questa specifica descrive solo il formato generale; gli schemi di autenticazione che utilizzano Authentication-Info definiranno i singoli parametri. Ad esempio, lo schema di autenticazione "Digest" definisce diversi parametri nella Sezione 3.5 di [RFC7616].
Authentication-Info = #auth-param
Il campo Authentication-Info può essere utilizzato in qualsiasi risposta HTTP, indipendentemente dal metodo di richiesta e dal codice di stato. La sua semantica è definita dallo schema di autenticazione indicato dal campo di intestazione Authorization (Sezione 11.6.2) della richiesta corrispondente.
Un proxy che inoltra una risposta non è autorizzato a modificare il valore del campo in alcun modo.
Authentication-Info può essere inviato come campo trailer (Sezione 6.5) una volta che diventa chiaro che il corpo del messaggio sarà inviato (ad esempio, l'autenticazione non viene rifiutata), quando lo schema di autenticazione lo consente esplicitamente.
11.7. Autenticazione dei Client ai Proxy (Authenticating Clients to Proxies)
11.7.1. Proxy-Authenticate
Il campo di intestazione "Proxy-Authenticate" consiste in almeno una challenge che indica lo schema o gli schemi di autenticazione e i parametri applicabili al proxy per questa richiesta. Un proxy DEVE (MUST) inviare almeno un campo di intestazione Proxy-Authenticate in ogni risposta 407 (Proxy Authentication Required) che genera.
Proxy-Authenticate = #challenge
A differenza di WWW-Authenticate, il campo di intestazione Proxy-Authenticate si applica solo al client in uscita successivo nella catena di risposta. Questo perché solo il client che ha scelto un dato proxy è probabile che abbia le credenziali necessarie per l'autenticazione. Tuttavia, quando vengono utilizzati più proxy all'interno dello stesso dominio amministrativo, come i proxy di caching d'ufficio e regionali in una grande rete aziendale, è comune che le credenziali vengano generate dallo user agent e passate attraverso la gerarchia fino al consumo. Pertanto, in tale configurazione, sembrerà che Proxy-Authenticate venga inoltrato poiché ogni proxy invierà lo stesso insieme di challenge.
Si noti che le considerazioni di parsing per WWW-Authenticate si applicano anche a questo campo di intestazione; vedere la Sezione 11.6.1 per i dettagli.
11.7.2. Proxy-Authorization
Il campo di intestazione "Proxy-Authorization" consente al client di identificare se stesso (o il suo utente) a un proxy che richiede l'autenticazione. Il suo valore consiste in credenziali contenenti le informazioni di autenticazione del client per il proxy e/o il realm della risorsa richiesta.
Proxy-Authorization = credentials
A differenza di Authorization, il campo di intestazione Proxy-Authorization si applica solo al proxy in entrata successivo che ha richiesto l'autenticazione utilizzando il campo di intestazione Proxy-Authenticate. Quando vengono utilizzati più proxy in una catena, il campo di intestazione Proxy-Authorization viene consumato dal primo proxy in entrata che si aspettava di ricevere credenziali. Un proxy PUÒ (MAY) inoltrare le credenziali dalla richiesta del client al proxy successivo se questo è il meccanismo con cui i proxy cooperano per autenticare una determinata richiesta.
11.7.3. Proxy-Authentication-Info
Il campo di intestazione di risposta "Proxy-Authentication-Info" è equivalente a Authentication-Info, tranne per il fatto che si applica all'autenticazione proxy (Sezione 11.3) e che la sua semantica è definita dallo schema di autenticazione indicato dal campo di intestazione Proxy-Authorization (Sezione 11.7.2) della richiesta corrispondente:
Proxy-Authentication-Info = #auth-param
Tuttavia, a differenza di Authentication-Info, il campo di intestazione Proxy-Authentication-Info si applica solo al client in uscita successivo nella catena di risposta. Questo perché solo il client che ha scelto un dato proxy è probabile che abbia le credenziali necessarie per l'autenticazione. Tuttavia, quando vengono utilizzati più proxy all'interno dello stesso dominio amministrativo, come i proxy di caching d'ufficio e regionali in una grande rete aziendale, è comune che le credenziali vengano generate dallo user agent e passate attraverso la gerarchia fino al consumo. Pertanto, in tale configurazione, sembrerà che Proxy-Authentication-Info venga inoltrato poiché ogni proxy invierà lo stesso valore di campo.
Proxy-Authentication-Info può essere inviato come campo trailer (Sezione 6.5) una volta che diventa chiaro che il corpo del messaggio sarà inviato, quando lo schema di autenticazione lo consente esplicitamente.