Per una pagina Web esistente, ma per la quale un utente non dispone di privilegi sufficienti (non ha effettuato l'accesso o non appartiene al gruppo utenti appropriato), qual è la risposta HTTP corretta da offrire?

401 Unauthorized?
403 Forbidden?
Qualcos'altro?

Quello che ho letto su ciascuno finora non è molto chiaro sulla differenza tra i due. Quali casi d'uso sono appropriati per ogni risposta?

Una chiara spiegazione di Daniel Irvine :

Si è verificato un problema con 401 non autorizzato , il codice di stato HTTP per errori di autenticazione. E questo è tutto: è per autenticazione, non autorizzazione. Ricezione di una risposta 401 è il server che ti dice "non sei autenticato, o non sei autenticato o autenticato in modo errato, ma ti preghiamo di riautenticare e riprovare." Per aiutarti, includerà sempre un'intestazione WWW-Authenticate che descrive come eseguire l'autenticazione.

Questa è una risposta generalmente restituita dal tuo server web, non dalla tua applicazione web.

È anche qualcosa di molto temporaneo; il server ti sta chiedendo di riprovare.

Quindi, per l'autorizzazione, utilizzo la risposta proibita 403 . È permanente, è legato alla mia logica applicativa ed è una risposta più concreta di un 401.

Ricezione di una risposta 403 è il server che ti dice: "Mi dispiace. So chi sei, credo chi dici di essere, ma non hai il permesso di accedere a questa risorsa. Forse se chiedi bene all'amministratore di sistema, otterrai l'autorizzazione. Ma per favore non disturbarmi di nuovo fino a quando la tua situazione non cambierà. "

In breve, una risposta 401 non autorizzata dovrebbe essere utilizzata per un'autenticazione mancante o errata e una risposta proibita 403 in seguito dovrebbe essere utilizzata, quando l'utente è autenticato ma non è autorizzato a eseguire l'operazione richiesta sulla risorsa specificata.

Un altro bel formato pittorico di come utilizzare i codici di stato http.

Vedi RFC2616 :

401 non autorizzato:

Se la richiesta includeva già le credenziali di autorizzazione, la risposta 401 indica che l'autorizzazione è stata rifiutata per tali credenziali.

403 proibito:

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla.

Aggiornare

Dal tuo caso d'uso, sembra che l'utente non sia autenticato. Vorrei restituire 401.

Modifica: RFC2616 è obsoleto, vedere RFC7231 e RFC7235 .

Qualcosa che manca alle altre risposte è che bisogna capire che Autenticazione e Autorizzazione nel contesto di RFC 2616 si riferisce SOLO al protocollo di autenticazione HTTP di RFC 2617. L'autenticazione mediante schemi esterni a RFC2617 non è supportata nei codici di stato HTTP e non viene considerata quando si decide se utilizzare 401 o 403.

Breve e conciso

Non autorizzato indica che il client non è autenticato RFC2617 e che il server sta avviando il processo di autenticazione. Proibito indica che il client è autenticato RFC2617 e non dispone di autorizzazione o che il server non supporta RFC2617 per la risorsa richiesta.

Significa che se hai il tuo processo di accesso roll-your-own e non usi mai l'autenticazione HTTP, 403 è sempre la risposta corretta e 401 non dovrebbe mai essere usato.

Dettagliato e approfondito

Da RFC2616

10.4.2 401 Non autorizzato

La richiesta richiede l'autenticazione dell'utente. La risposta DEVE includere un campo di intestazione WWW-Authenticate (sezione 14.47) contenente una sfida applicabile alla risorsa richiesta. Il cliente può ripetere la richiesta con un campo di intestazione Autorizzazione adeguato (sezione 14.8).

e

10.4.4 403 Proibito Il server ha compreso la richiesta ma si rifiuta di soddisfarla. L'autorizzazione non aiuterà e la richiesta NON DOVREBBE essere ripetuta.

La prima cosa da tenere a mente è che "Autenticazione" e "Autorizzazione" nel contesto di questo documento si riferiscono specificamente ai protocolli di autenticazione HTTP di RFC 2617. Non si riferiscono ad alcun protocollo di autenticazione roll-your-own che potresti aver creato utilizzando le pagine di accesso, ecc. Userò "login" per fare riferimento all'autenticazione e all'autorizzazione con metodi diversi da RFC2617

Quindi la vera differenza non è il problema o anche se esiste una soluzione. La differenza è ciò che il server si aspetta che faccia il client.

401 indica che la risorsa non può essere fornita, ma il server RICHIEDE che il client acceda tramite l'autenticazione HTTP e abbia inviato le intestazioni di risposta per avviare il processo. Forse ci sono autorizzazioni che permetteranno l'accesso alla risorsa, forse non ci sono, ma proviamolo e vediamo cosa succede.

403 indica che la risorsa non può essere fornita e per l'utente corrente non esiste alcun modo per risolverlo tramite RFC2617 e non ha senso tentare. Ciò può essere dovuto al fatto che è noto che nessun livello di autenticazione è sufficiente (ad esempio a causa di una lista nera IP), ma può essere dovuto al fatto che l'utente è già autenticato e non dispone dell'autorizzazione. Il modello RFC2617 è un utente e una delle credenziali, pertanto il caso in cui l'utente può disporre di una seconda serie di credenziali che potrebbero essere autorizzate può essere ignorato. Né suggerisce né implica che una sorta di pagina di accesso o altri protocolli di autenticazione non RFC2617 possano o meno aiutare, al di fuori degli standard e delle definizioni RFC2616.

Modifica: RFC2616 è obsoleto, vedere RFC7231 e RFC7235 .

  + -----------------------
  | ESISTENTI ALLE RISORSE? (se privato è spesso controllato DOPO il controllo di autenticazione)
  + -----------------------
    | |
 NO | v SÌ
    v + -----------------------
   404 | È COLLEGATO? (autenticato, aka ha sessione o cookie JWT)
   o + -----------------------
   401 | |
   403 NO | | SÌ
   3xx vv
              401 + -----------------------
       (404 nessuna rivelazione) | PU ACCESS ACCEDERE ALLE RISORSE? (permesso, autorizzato, ...)
              o + -----------------------
             reindirizzamento | |
             per accedere NO | | SÌ
                               | |
                               vv
                               403 OK 200, reindirizzamento, ...
                      (o 404: nessuna rivelazione)
                      (o 404: la risorsa non esiste se privata)
                      (o 3xx: reindirizzamento)

I controlli vengono generalmente eseguiti in questo ordine:

• 404 se la risorsa è pubblica e non esiste o reindirizzamento 3xx
• ALTRIMENTI:
• 401 se non si è effettuato l'accesso o la sessione è scaduta
• 403 se l'utente non dispone dell'autorizzazione per accedere alla risorsa (file, json, ...)
• 404 se la risorsa non esiste o non è disposta a rivelare nulla, o reindirizzamento 3xx

NON AUTORIZZATO : codice di stato (401) che indica che la richiesta richiede autenticazione , in genere significa che l'utente deve aver effettuato l'accesso (sessione). Utente / agente sconosciuto dal server. Può ripetere con altre credenziali. NOTA: questo è fonte di confusione in quanto avrebbe dovuto essere chiamato "non autenticato" anziché "non autorizzato". Questo può accadere anche dopo il login se la sessione è scaduta. Caso speciale: può essere utilizzato al posto di 404 per evitare la presenza o la non presenza di risorse rivelanti (credits @gingerCodeNinja)

VIETATO : codice di stato (403) che indica che il server ha compreso la richiesta ma ha rifiutato di soddisfarla. Utente / agente noto dal server ma con credenziali insufficienti . La richiesta ripetuta non funzionerà, a meno che le credenziali non vengano modificate, il che è molto improbabile in breve tempo. Caso speciale: può essere utilizzato al posto di 404 per evitare la presenza o la non presenza di risorse rivelanti (credits @gingerCodeNinja)

NON TROVATO : codice di stato (404) che indica che la risorsa richiesta non è disponibile. Utente / agente noto ma il server non rivelerà nulla sulla risorsa, come se non esistesse. La ripetizione non funzionerà. Questo è un uso speciale di 404 (ad esempio github).

Come menzionato da @ChrisH ci sono alcune opzioni per il reindirizzamento 3xx (301, 302, 303, 307 o per non reindirizzare affatto e usando un 401):

• Differenza tra i codici di reindirizzamento HTTP
• Per quanto tempo i browser memorizzano nella cache HTTP 301s?
• Qual è il codice di stato HTTP corretto quando si reindirizza a una pagina di accesso?
• Qual è la differenza tra un reindirizzamento 302 e 307?

Secondo RFC 2616 (HTTP / 1.1) 403 viene inviato quando:

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla. L'autorizzazione non aiuterà e la richiesta NON DOVREBBE essere ripetuta. Se il metodo di richiesta non era HEAD e il server desidera rendere pubblico il motivo per cui la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo del rifiuto nell'entità. Se il server non desidera rendere disponibili queste informazioni al client, è possibile utilizzare invece il codice di stato 404 (Not Found)

In altre parole, se il client PU get accedere alla risorsa autenticandosi, dovrebbe essere inviato 401.

Supponendo che sia in uso l' autenticazione HTTP ( intestazioni WWW-Authenticate and Authorization ) , se l'autenticazione come un altro utente consentirebbe l'accesso alla risorsa richiesta, allora dovrebbe essere restituito 401 Non autorizzato.

403 Proibito viene utilizzato quando l'accesso alla risorsa è vietato a tutti o limitato a una determinata rete o consentito solo su SSL, a condizione che non sia correlato all'autenticazione HTTP.

Se l'autenticazione HTTP non è in uso e il servizio prevede uno schema di autenticazione basato su cookie come è oggigiorno la norma, è necessario restituire un 403 o un 404.

Per quanto riguarda 401, questo è da RFC 7235 (Hypertext Transfer Protocol (HTTP / 1.1): Autenticazione):

3.1. 401 Non autorizzato

Il codice di stato 401 (non autorizzato) indica che la richiesta non è stata applicata perché manca di credenziali di autenticazione valide per la risorsa di destinazione. Il server di origine DEVE inviare un campo di intestazione WWW-Authenticate (Sezione 4.4) contenente almeno una sfida applicabile alla risorsa di destinazione. Se la richiesta includeva credenziali di autenticazione, la risposta 401 indica che l'autorizzazione è stata rifiutata per tali credenziali. Il cliente può ripetere la richiesta con un campo di intestazione Autorizzazione nuovo o sostituito (Sezione 4.1). Se la risposta 401 contiene la stessa sfida della risposta precedente e l'agente utente ha già tentato l'autenticazione almeno una volta, l'agente utente DOVREBBE presentare all'utente la rappresentazione allegata, poiché di solito contiene informazioni diagnostiche pertinenti.

La semantica di 403 (e 404) è cambiata nel tempo. Questo è del 1999 (RFC 2616):

10.4.4 403 Proibito

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla.
L'autorizzazione non sarà di aiuto e la richiesta NON DOVREBBE essere ripetuta.
Se il metodo di richiesta non era HEAD e il server desidera rendere
pubblico il motivo per cui la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo del rifiuto nell'entità. Se il server non desidera rendere disponibili queste informazioni al client, è
possibile utilizzare invece il codice di stato 404 (Not Found).

Nel 2014 RFC 7231 (Hypertext Transfer Protocol (HTTP / 1.1): Semantica e contenuto) ha cambiato il significato di 403:

6.5.3. 403 proibito

Il codice di stato 403 (proibito) indica che il server ha compreso la richiesta ma si rifiuta di autorizzarla. Un server che desidera rendere pubblico il motivo per cui la richiesta è stata vietata può descrivere tale motivo nel payload di risposta (se presente).

Se nella richiesta sono state fornite credenziali di autenticazione, il
server le considera insufficienti per consentire l'accesso. Il client
NON DOVREBBE ripetere automaticamente la richiesta con le stesse
credenziali. Il cliente può ripetere la richiesta con credenziali nuove o diverse. Tuttavia, una richiesta potrebbe essere vietata per motivi
non correlati alle credenziali.

Un server di origine che desidera "nascondere" l'esistenza attuale di una
risorsa di destinazione vietata PU instead invece rispondere con un codice di stato
404 (non trovato).

Pertanto, un 403 (o un 404) potrebbe ora significare qualsiasi cosa. Fornire nuove credenziali potrebbe aiutare ... oppure no.

Credo che il motivo per cui questo è cambiato sia RFC 2616 supponendo che l'autenticazione HTTP verrebbe utilizzata quando in pratica le app Web di oggi sviluppano schemi di autenticazione personalizzati utilizzando ad esempio moduli e cookie.

Questa è una domanda più vecchia, ma un'opzione che non è mai stata davvero sollevata è quella di restituire un 404. Dal punto di vista della sicurezza, la risposta più votata soffre di una potenziale vulnerabilità di perdita di informazioni . Supponiamo, ad esempio, che la pagina Web protetta in questione sia una pagina di amministrazione del sistema, o forse più comunemente, sia un record in un sistema a cui l'utente non ha accesso. Idealmente non vorresti che un utente malintenzionato sapesse nemmeno che c'è una pagina / record lì, figuriamoci che non hanno accesso. Quando sto costruendo qualcosa del genere, proverò a registrare richieste non autenticate / non autorizzate in un registro interno, ma restituirò un 404.

OWASP ha alcune informazioni in più su come un utente malintenzionato potrebbe utilizzare questo tipo di informazioni come parte di un attacco.

• 401 Non autorizzato : non so chi sei. Questo è un errore di autenticazione.
• 403 Proibito : so chi sei, ma non hai i permessi per accedere a questa risorsa. Questo è un errore di autorizzazione.

Questa domanda è stata posta qualche tempo fa, ma il pensiero della gente va avanti.

La sezione 6.5.3 di questa bozza (creata da Fielding e Reschke) dà al codice di stato 403 un significato leggermente diverso da quello documentato in RFC 2616 .

Riflette ciò che accade negli schemi di autenticazione e autorizzazione utilizzati da numerosi server Web e framework popolari.

Ho sottolineato la parte che ritengo più saliente.

6.5.3. 403 proibito

Il codice di stato 403 (proibito) indica che il server ha compreso la richiesta ma si rifiuta di autorizzarla. Un server che desidera rendere pubblico il motivo per cui la richiesta è stata vietata può descrivere tale motivo nel payload di risposta (se presente).

Se nella richiesta sono state fornite credenziali di autenticazione, il server le considera insufficienti per consentire l'accesso. Il client NON DOVREBBE ripetere la richiesta con le stesse credenziali. Il cliente può ripetere la richiesta con credenziali nuove o diverse. Tuttavia, una richiesta potrebbe essere vietata per motivi non correlati alle credenziali.

Un server di origine che desidera "nascondere" l'esistenza attuale di una risorsa di destinazione vietata PUO 'invece rispondere con un codice di stato 404 (non trovato).

Qualunque sia la convenzione che utilizzi, l'importante è fornire uniformità nel tuo sito / API.

TL; DR

• 401: Un rifiuto che ha a che fare con l'autenticazione
• 403: Un rifiuto che non ha nulla a che fare con l'autenticazione

Esempi pratici

Se apache richiede l'autenticazione (via .htaccess) e si preme Cancel, risponderà con a401 Authorization Required

Se nginx trova un file, ma non ha diritti di accesso (utente / gruppo) per leggerlo / accedervi, risponderà403 Forbidden

RFC (2616 Sezione 10)

401 non autorizzato (10.4.2)

Significato 1: necessità di autenticare

La richiesta richiede l'autenticazione dell'utente. ...

Significato 2: autenticazione insufficiente

... Se la richiesta includeva già le credenziali di autorizzazione, la risposta 401 indica che l'autorizzazione è stata rifiutata per tali credenziali. ...

403 proibito (10.4.4)

Significato: non correlato all'autenticazione

... L'autorizzazione non aiuterà ...

Più dettagli:

• Il server ha compreso la richiesta, ma si rifiuta di soddisfarla.

• DOVREBBE descrivere il motivo del rifiuto nell'entità

• In alternativa, è possibile utilizzare il codice di stato 404 (Non trovato)

  (Se il server desidera mantenere queste informazioni dal client)

non sono connessi o non appartengono al gruppo utenti corretto

Hai dichiarato due casi diversi; ogni caso dovrebbe avere una risposta diversa:

1. Se non hanno effettuato l'accesso, è necessario restituire 401 Non autorizzato
2. Se sono connessi ma non appartengono al gruppo utenti corretto, è necessario restituire 403 proibito

Nota sulla RFC sulla base dei commenti ricevuti a questa risposta:

Se l'utente non ha effettuato l'accesso, non è autenticato, il cui equivalente HTTP è 401 ed è fuorviante chiamato Non autorizzato nella RFC. Come indicato nella sezione 10.4.2 per 401 Non autorizzato :

"La richiesta richiede l' autenticazione dell'utente ."

Se non sei autenticato, 401 è la risposta corretta. Tuttavia, se non sei autorizzato, nel senso semanticamente corretto, 403 è la risposta corretta.

Questi sono i significati:

401 : Utente non (correttamente) autenticato, la risorsa / pagina richiede autenticazione

403 : Utente autenticato, ma il suo ruolo o le sue autorizzazioni non consentono di accedere alla risorsa richiesta, ad esempio l'utente non è un amministratore e la pagina richiesta è per gli amministratori

Questo è più semplice nella mia testa che ovunque qui, quindi:

401: Per vedere questo è necessario l'autenticazione di base HTTP.

403: Non puoi vederlo e l'autenticazione di base HTTP non ti aiuterà.

Se l'utente deve semplicemente accedere utilizzando il modulo di accesso HTML standard del tuo sito, 401 non sarebbe appropriato perché è specifico dell'autent di base HTTP.

Non consiglio di usare 403 per negare l'accesso a cose come /includes, perché per quanto riguarda il web, quelle risorse non esistono affatto e dovrebbero quindi 404.

Questo lascia 403 come "devi essere loggato".

In altre parole, 403 significa "questa risorsa richiede una forma di autenticazione diversa dall'autent di base HTTP".

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

Penso che sia importante considerare che, per un browser, 401 avvia una finestra di autenticazione per l'utente di inserire nuove credenziali, mentre 403 no. I browser pensano che, se viene restituito un 401, l'utente dovrebbe eseguire nuovamente l'autenticazione. Quindi 401 indica autenticazione non valida mentre 403 indica mancanza di autorizzazione.

Ecco alcuni casi in quella logica in cui un errore verrebbe restituito dall'autenticazione o dall'autorizzazione, con frasi importanti in grassetto.

• Una risorsa richiede autenticazione ma non sono state specificate credenziali .

401 : il client deve specificare le credenziali.

• Le credenziali specificate sono in un formato non valido .

400 : Non è né 401 né 403, poiché gli errori di sintassi dovrebbero sempre restituire 400.

• Le credenziali specificate fanno riferimento a un utente che non esiste .

401 : il client deve specificare credenziali valide.

• Le credenziali specificate non sono valide ma specificano un utente valido (o non specificare un utente se non è richiesto un utente specificato).

401 : Ancora una volta, il client deve specificare credenziali valide.

• Le credenziali specificate sono scadute .

401 : Questo è praticamente lo stesso di avere credenziali non valide in generale, quindi il cliente deve specificare credenziali valide.

• Le credenziali specificate sono completamente valide ma non sono sufficienti per la particolare risorsa , sebbene sia possibile che le credenziali con più autorizzazioni possano farlo.

403 : La specifica di credenziali valide non consentirebbe l'accesso alla risorsa, poiché le credenziali correnti sono già valide ma solo non dispongono dell'autorizzazione.

• La particolare risorsa è inaccessibile indipendentemente dalle credenziali.

403 : indipendentemente dalle credenziali, pertanto non è possibile specificare le credenziali valide.

• Le credenziali specificate sono completamente validi ma la particolare cliente viene bloccato dal loro utilizzo.

403 : se il client è bloccato, specificare nuove credenziali non farà nulla.

In inglese:

401

Potresti potenzialmente accedere, ma per qualche motivo su questa richiesta ti è stato negato. Come una password sbagliata? Riprova, con la richiesta corretta otterrai invece una risposta positiva.

403

Non ti è mai permesso. Il tuo nome non è nell'elenco, non entrerai mai, vai via, non inviare una richiesta di riprovare, verrà rifiutato, sempre. Va via.

Dati gli ultimi RFC in materia ( 7231 e 7235 ), il caso d'uso sembra abbastanza chiaro (corsivo aggiunto):

• 401 non è autenticato ("manca un'autenticazione valida"); cioè "Non so chi sei o non mi fido di te chi dici di essere".

401 Non autorizzato

Il codice di stato 401 (non autorizzato) indica che la richiesta non è stata applicata perché manca di credenziali di autenticazione valide per la risorsa di destinazione. Il server che genera una risposta 401 DEVE inviare un campo di intestazione WWW-Authenticate (Sezione 4.1) contenente almeno una sfida applicabile alla risorsa di destinazione.

Se la richiesta includeva credenziali di autenticazione, la risposta 401 indica che l'autorizzazione è stata rifiutata per tali credenziali. L'agente utente PUO 'ripetere la richiesta con un campo di intestazione Autorizzazione nuovo o sostituito (Sezione 4.2). Se la risposta 401 contiene la stessa sfida della risposta precedente e l'agente utente ha già tentato l'autenticazione almeno una volta, l'agente utente DOVREBBE presentare all'utente la rappresentazione allegata, poiché di solito contiene informazioni diagnostiche pertinenti.

• 403 è per non autorizzato ("rifiuta di autorizzare"); cioè "So chi sei, ma non hai i permessi per accedere a questa risorsa".

403 proibito

Il codice di stato 403 (proibito) indica che il server ha compreso la richiesta ma rifiuta di autorizzarla . Un server che desidera rendere pubblico il motivo per cui la richiesta è stata vietata può descrivere tale motivo nel payload di risposta (se presente).

Se nella richiesta sono state fornite credenziali di autenticazione, il server le considera insufficienti per consentire l'accesso. Il client NON DOVREBBE ripetere automaticamente la richiesta con le stesse credenziali. Il cliente può ripetere la richiesta con credenziali nuove o diverse. Tuttavia, una richiesta potrebbe essere vietata per motivi non correlati alle credenziali.

Un server di origine che desidera "nascondere" l'esistenza attuale di una risorsa di destinazione vietata PU instead invece rispondere con un codice di stato 404 (non trovato).

Nel caso di 401 vs 403, questo è stato risposto più volte. Questo è essenzialmente un dibattito "HTTP request environment", non un dibattito "application".

Sembra che ci sia una domanda sul problema roll-your-own-login (applicazione).

In questo caso, semplicemente non effettuare l'accesso non è sufficiente per inviare un 401 o un 403, a meno che non si utilizzi HTTP Auth vs una pagina di accesso (non legata all'impostazione di HTTP Auth). Sembra che tu stia cercando un "201 creato", con una schermata roll-your-own-login presente (invece della risorsa richiesta) per l'accesso a livello di applicazione a un file. Questo dice:

"Ti ho sentito, è qui, ma prova questo (non ti è permesso vederlo)"