2. Lo schema di autenticazione 'Basic'
Lo schema di autenticazione Basic si basa sul modello secondo cui il client deve autenticarsi con uno user-id e una password per ogni spazio di protezione ("realm"). Il valore del realm è una stringa in formato libero che può essere confrontata solo per uguaglianza con altri realm su quel server. Il server elaborerà la richiesta solo se può validare lo user-id e la password per lo spazio di protezione applicabile alla risorsa richiesta.
Lo schema di autenticazione Basic utilizza il Framework di Autenticazione come segue.
Nelle challenge:
- Il nome dello schema è "Basic".
- Il parametro di autenticazione 'realm' è OBBLIGATORIO (REQUIRED) ([RFC7235], Sezione 2.2).
- Il parametro di autenticazione 'charset' è OPZIONALE (OPTIONAL) (vedere Sezione 2.1).
- Nessun altro parametro di autenticazione è definito -- i parametri sconosciuti DEVONO essere ignorati dai destinatari, e nuovi parametri possono essere definiti solo rivedendo questa specifica.
Vedere anche la Sezione 4.1 di [RFC7235], che discute la complessità dell'analisi corretta delle challenge.
Si noti che sia i nomi dello schema che dei parametri vengono confrontati senza distinzione tra maiuscole e minuscole.
Per le credenziali, viene utilizzata la sintassi "token68" definita nella Sezione 2.1 di [RFC7235]. Il valore viene calcolato in base allo user-id e alla password come definito di seguito.
Alla ricezione di una richiesta per un URI all'interno dello spazio di protezione che manca di credenziali, il server può rispondere con una challenge utilizzando il codice di stato 401 (Unauthorized) ([RFC7235], Sezione 3.1) e il campo di intestazione WWW-Authenticate ([RFC7235], Sezione 4.1).
Ad esempio:
HTTP/1.1 401 Unauthorized
Date: Mon, 04 Feb 2014 16:50:53 GMT
WWW-Authenticate: Basic realm="WallyWorld"
dove "WallyWorld" è la stringa assegnata dal server per identificare lo spazio di protezione.
Un proxy può rispondere con una challenge simile utilizzando il codice di stato 407 (Proxy Authentication Required) ([RFC7235], Sezione 3.2) e il campo di intestazione Proxy-Authenticate ([RFC7235], Sezione 4.3).
Per ricevere l'autorizzazione, il client
- ottiene lo user-id e la password dall'utente,
- costruisce lo user-pass concatenando lo user-id, un singolo carattere due punti (":"), e la password,
- codifica lo user-pass in una sequenza di ottetti (vedere di seguito per una discussione sugli schemi di codifica dei caratteri),
- e ottiene le basic-credentials codificando questa sequenza di ottetti utilizzando Base64 ([RFC4648], Sezione 4) in una sequenza di caratteri US-ASCII ([RFC0020]).
La definizione originale di questo schema di autenticazione non ha specificato lo schema di codifica dei caratteri utilizzato per convertire lo user-pass in una sequenza di ottetti. In pratica, la maggior parte delle implementazioni ha scelto una codifica specifica della locale come ISO-8859-1 ([ISO-8859-1]), o UTF-8 ([RFC3629]). Per motivi di retrocompatibilità, questa specifica continua a lasciare la codifica predefinita non definita, purché sia compatibile con US-ASCII (mappando qualsiasi carattere US-ASCII su un singolo ottetto corrispondente al codice carattere US-ASCII).
Lo user-id e la password NON DEVONO contenere alcun carattere di controllo (vedere "CTL" nell'Appendice B.1 di [RFC5234]).
Inoltre, uno user-id contenente un carattere due punti è invalido, poiché il primo due punti in una stringa user-pass separa user-id e password l'uno dall'altra; il testo dopo il primo due punti fa parte della password. Gli user-id contenenti due punti non possono essere codificati nelle stringhe user-pass.
Si noti che molti user agent producono stringhe user-pass senza verificare che gli user-id forniti dagli utenti non contengano due punti; i destinatari tratteranno quindi parte dell'input del nome utente come parte della password.
Se lo user agent desidera inviare lo user-id "Aladdin" e la password "open sesame", utilizzerebbe il seguente campo di intestazione:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
2.1. Il parametro auth-param 'charset'
Nelle challenge, i server possono utilizzare il parametro di autenticazione 'charset' per indicare lo schema di codifica dei caratteri che si aspettano che lo user agent utilizzi quando genera "user-pass" (una sequenza di ottetti). Questa informazione è puramente consultiva.
L'unico valore consentito è "UTF-8"; deve essere confrontato senza distinzione tra maiuscole e minuscole (vedere [RFC2978], Sezione 2.3). Indica che il server si aspetta che i dati dei caratteri siano convertiti in forma di normalizzazione Unicode C ("NFC"; vedere Sezione 3 di [RFC5198]) e codificati in ottetti utilizzando lo schema di codifica dei caratteri UTF-8 ([RFC3629]).
Per lo user-id, i destinatari DEVONO supportare tutti i caratteri definiti nel profilo "UsernameCasePreserved" definito nella Sezione 3.3 di [RFC7613], ad eccezione del carattere due punti (":").
Per la password, i destinatari DEVONO supportare tutti i caratteri definiti nel profilo "OpaqueString" definito nella Sezione 4.2 di [RFC7613].
Altri valori sono riservati per uso futuro.
Nota: Il 'charset' è definito solo nelle challenge, poiché l'autenticazione Basic utilizza un singolo token per le credenziali (sintassi 'token68'); quindi, la sintassi delle credenziali non è estensibile.
Nota: Il nome 'charset' è stato scelto per coerenza con la Sezione 2.1.1 di [RFC2831]. Un nome migliore sarebbe stato 'accept-charset', poiché non riguarda il messaggio in cui appare, ma l'aspettativa del server.
Nell'esempio seguente, il server richiede l'autenticazione nel realm "foo", utilizzando l'autenticazione Basic, con una preferenza per lo schema di codifica dei caratteri UTF-8:
WWW-Authenticate: Basic realm="foo", charset="UTF-8"
Si noti che il valore del parametro può essere un token o una stringa tra virgolette; in questo caso, il server ha scelto di utilizzare la notazione con stringa tra virgolette.
Il nome dell'utente è "test", e la password è la stringa "123" seguita dal carattere Unicode U+00A3 (POUND SIGN). Utilizzando lo schema di codifica dei caratteri UTF-8, lo user-pass diventa:
't' 'e' 's' 't' ':' '1' '2' '3' pound
74 65 73 74 3A 31 32 33 C2 A3
Codificando questa sequenza di ottetti in Base64 ([RFC4648], Sezione 4) si ottiene:
dGVzdDoxMjPCow==
Pertanto, il campo di intestazione Authorization sarebbe:
Authorization: Basic dGVzdDoxMjPCow==
O, per l'autenticazione proxy:
Proxy-Authorization: Basic dGVzdDoxMjPCow==
2.2. Riutilizzo delle credenziali
Dato l'URI assoluto ([RFC3986], Sezione 4.3) di una richiesta autenticata, l'ambito di autenticazione di quella richiesta si ottiene rimuovendo tutti i caratteri dopo l'ultimo carattere barra ("/") del componente percorso ("hier_part"; vedere [RFC3986], Sezione 3). Un client DOVREBBE presumere che le risorse identificate da URI con una corrispondenza di prefisso dell'ambito di autenticazione siano anch'esse all'interno dello spazio di protezione specificato dal valore del realm di quella richiesta autenticata.
Un client PUÒ inviare preventivamente il campo di intestazione Authorization corrispondente con richieste per risorse in quello spazio senza ricevere un'altra challenge dal server. Similmente, quando un client invia una richiesta a un proxy, PUÒ riutilizzare uno user-id e una password nel campo di intestazione Proxy-Authorization senza ricevere un'altra challenge dal server proxy.
Ad esempio, data una richiesta autenticata a:
http://example.com/docs/index.html
le richieste agli URI seguenti potrebbero utilizzare le credenziali note:
http://example.com/docs/
http://example.com/docs/test.doc
http://example.com/docs/?page=1
mentre gli URI
http://example.com/other/
https://example.com/docs/
sarebbero considerati al di fuori dell'ambito di autenticazione.
Si noti che un URI può far parte di più ambiti di autenticazione (come "http://example.com/" e "http://example.com/docs/"). Questa specifica non definisce quale di questi debba essere trattato con priorità più alta.