2. Framework di autenticazione dell'accesso
2.1 Challenge e risposta
HTTP fornisce un semplice framework di autenticazione challenge-response che può essere usato da un server per lanciare una challenge a una richiesta del client e da un client per fornire informazioni di autenticazione. Utilizza un token senza distinzione tra maiuscole e minuscole per identificare lo schema di autenticazione, seguito dalle informazioni aggiuntive necessarie per ottenere l'autenticazione mediante tale schema. Queste ultime possono essere un elenco di parametri separati da virgole oppure una singola sequenza di caratteri in grado di contenere informazioni codificate in base64.
I parametri di autenticazione sono coppie nome=valore, in cui il token del nome viene confrontato senza distinzione tra maiuscole e minuscole e ogni nome di parametro deve comparire una sola volta per challenge (MUST).
auth-scheme = token
auth-param = token BWS "=" BWS ( token / quoted-string )
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
La sintassi token68 consente i 66 caratteri URI non riservati ([RFC3986]), più alcuni altri, in modo da poter 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]).
Un messaggio di risposta 401 (Unauthorized) è usato da un server di origine per contestare l'autorizzazione di uno user agent, e comprende un campo di intestazione WWW-Authenticate contenente almeno una challenge applicabile alla risorsa richiesta.
Un messaggio di risposta 407 (Proxy Authentication Required) è usato da un proxy per contestare l'autorizzazione di un client, e comprende 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 che contiene uno schema sconosciuto. Una soluzione a questo problema consiste nell'elencare per primi gli schemi ben supportati (come "basic").
Uno user agent che desidera autenticarsi presso un server di origine — di norma, ma non necessariamente, dopo aver ricevuto una 401 (Unauthorized) — può farlo includendo un campo di intestazione Authorization nella richiesta.
Un client che desidera autenticarsi presso un proxy — di norma, ma non necessariamente, dopo aver ricevuto una 407 (Proxy Authentication Required) — può farlo includendo un campo di intestazione Proxy-Authorization nella richiesta.
Sia il valore del campo Authorization sia il valore del campo Proxy-Authorization contengono le credenziali del client per il realm della risorsa richiesta, in base a una challenge ricevuta in una risposta (possibilmente in un momento precedente). Nel creare tali valori, lo user agent dovrebbe scegliere la challenge con quello che ritiene lo schema di autenticazione più sicuro tra quelli che comprende, ottenendo le credenziali dall'utente secondo necessità. La trasmissione di credenziali all'interno dei valori dei campi di intestazione implica importanti considerazioni di sicurezza riguardo alla riservatezza della connessione sottostante, come descritto nella Sezione 6.1.
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
Al ricevimento di una richiesta per una risorsa protetta che omette le credenziali, contiene credenziali non valide (ad esempio una password errata) o parziali (ad esempio quando lo schema di autenticazione richiede più di un round trip), un server di origine dovrebbe inviare una risposta 401 (Unauthorized) che contiene un campo di intestazione WWW-Authenticate con almeno una challenge (possibilmente nuova) applicabile alla risorsa richiesta (SHOULD).
Analogamente, al ricevimento di una richiesta che omette le credenziali proxy o contiene credenziali proxy non valide o parziali, un proxy che richiede l'autenticazione dovrebbe generare una risposta 407 (Proxy Authentication Required) che contiene un campo di intestazione Proxy-Authenticate con almeno una challenge (possibilmente nuova) applicabile al proxy (SHOULD).
Un server che riceve credenziali valide ma non sufficienti per ottenere l'accesso dovrebbe rispondere con il codice di stato 403 (Forbidden) (Sezione 6.5.3 della [RFC7231]).
HTTP non limita le applicazioni a questo semplice framework challenge-response per l'autenticazione dell'accesso. Possono essere usati meccanismi aggiuntivi, quali l'autenticazione a livello di trasporto o tramite incapsulamento dei messaggi, con ulteriori campi di intestazione che specificano le informazioni di autenticazione. Tali meccanismi aggiuntivi, tuttavia, non sono definiti dalla presente specifica.
2.2 Spazio di protezione (realm)
Il parametro di autenticazione "realm" è riservato all'uso da parte degli schemi di autenticazione che desiderano indicare un ambito di protezione.
Uno spazio di protezione è definito dall'URI radice canonica (i componenti scheme e authority dell'URI effettiva della richiesta; vedere la Sezione 5.5 della [RFC7230]) del server a cui si accede, in combinazione con il valore realm, se presente. Tali realm consentono di suddividere 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ò contenere più challenge con lo stesso auth-scheme ma realm diversi.
Lo spazio di protezione determina il dominio sul quale le credenziali possono essere applicate automaticamente. Se una richiesta precedente è stata autorizzata, lo user agent può riutilizzare le stesse credenziali per tutte le altre richieste all'interno di tale spazio di protezione per un periodo determinato dallo schema di autenticazione, dai parametri e/o dalle preferenze dell'utente (come un timeout di inattività configurabile) (MAY). Salvo esplicita autorizzazione dello schema di autenticazione, un singolo spazio di protezione non può estendersi oltre l'ambito del proprio server.
Per ragioni storiche, un mittente deve generare soltanto la sintassi quoted-string (MUST). I destinatari potrebbero dover supportare sia la sintassi token sia quella quoted-string per la massima interoperabilità con i client esistenti che accettano entrambe le notazioni da molto tempo.