2. Schema di autenticazione di base (Basic Authentication Scheme)

Lo schema di autenticazione "basic" si basa sul modello secondo cui il client deve autenticarsi con un ID utente e una password per ogni dominio (Realm). Il valore del realm dovrebbe essere considerato una stringa opaca che può essere confrontata solo per uguaglianza con altri realm su quel server. Il server elaborerà la richiesta solo se può validare l'ID utente e la password per lo spazio di protezione del Request-URI. Non ci sono parametri di autenticazione opzionali.

Per l'autenticazione di base (Basic), il framework sopra descritto viene utilizzato come segue:

challenge   = "Basic" realm
credentials = "Basic" basic-credentials

Alla ricezione di una richiesta non autorizzata per un URI all'interno dello spazio di protezione, il server di origine può rispondere con una sfida come la seguente:

WWW-Authenticate: Basic realm="WallyWorld"

dove "WallyWorld" è la stringa assegnata dal server per identificare lo spazio di protezione del Request-URI. Un proxy può rispondere con la stessa sfida utilizzando il campo header Proxy-Authenticate.

Per ricevere l'autorizzazione, il client invia l'ID utente e la password, separati da un singolo carattere due punti (":"), all'interno di una stringa codificata in base64 [7] nelle credenziali.

basic-credentials = base64-user-pass
base64-user-pass  = <base64 [4] encoding of user-pass,
                     except not limited to 76 char/line>
user-pass   = userid ":" password
userid      = *<TEXT excluding ":">
password    = *TEXT

Gli ID utente potrebbero essere sensibili alle maiuscole/minuscole.

Se l'user agent desidera inviare l'ID utente "Aladdin" e la password "open sesame", utilizzerebbe il seguente campo header:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Il client dovrebbe presumere che tutti i percorsi alla profondità dell'ultimo elemento simbolico o più profondi nel campo path del Request-URI siano anch'essi all'interno dello spazio di protezione specificato dal valore Basic realm della sfida corrente. Il client può inviare preventivamente l'header Authorization corrispondente con richieste per risorse in quello spazio senza ricevere un'altra sfida dal server. Allo stesso modo, quando un client invia una richiesta a un proxy, può riutilizzare un ID utente e una password nel campo header Proxy-Authorization senza ricevere un'altra sfida dal server proxy. Vedere la sezione 4 per le considerazioni sulla sicurezza associate all'autenticazione di base.

---