401 vs 403: scegli lo stato giusto per una richiesta rifiutata

401 vs 403

401 vs 403: Unauthorized o Forbidden, e quale restituire | We.Inc

401 significa non autenticato, 403 significa autenticato ma non autorizzato. Rispondi a quattro domande su una richiesta e ottieni lo stato giusto, con header e codice.

Restituisci 401 Unauthorized quando la richiesta non ha credenziali valide: nessun token, una sessione scaduta, una firma errata. Accedere potrebbe risolvere, e la risposta deve includere un header WWW-Authenticate. Restituisci 403 Forbidden quando sai chi è il chiamante e comunque non può fare questa operazione, quindi accedere di nuovo non cambia nulla.

Unauthorized contro Forbidden

401 Unauthorized
403 Forbidden

Significa davvero
Non autenticato
Non autorizzato

Accedere servirà?
Sì
No

Header obbligatorio
WWW-Authenticate
Nessuno obbligatorio

Causa tipica
Token o sessione mancante o scaduto
Controllo di ruolo o di proprietà fallito

Il client dovrebbe
Accedere o aggiornare il token, poi riprovare
Fermarsi e mostrare un messaggio di accesso negato

Rispondi a quattro domande sulla richiesta che il tuo server sta rifiutando. Lo strumento restituisce lo stato da inviare, l'header che lo accompagna e un motivo di una riga da mettere in un commento nel codice. Copre anche il caso in cui preferisci non ammettere che la risorsa esista.

Indica se la richiesta è arrivata con delle credenziali.
Indica se quelle credenziali sono risultate valide.
Indica se questo chiamante ha il permesso per questa azione su questa risorsa.
Decidi se l'esistenza della risorsa deve restare nascosta a chi non ha accesso.

Il nome Unauthorized è un incidente storico. 401 riguarda l'autenticazione, chi sei; 403 riguarda l'autorizzazione, cosa puoi fare.
In una single page app, tratta 401 come il segnale per aggiornare il token o mostrare la schermata di accesso, e 403 come un messaggio che l'utente non può risolvere accedendo.
Usa 404 invece di 403 per le risorse private la cui esistenza è di per sé un dato sensibile, come l'id della fattura di un altro cliente.
Registra i 403 con l'id utente e il permesso che è fallito. Sono il modo più rapido per individuare un ruolo configurato male.

Domande frequenti

Qual è la differenza principale tra 401 e 403?

401 dice che il server non sa chi sei, o non ha accettato la prova che hai inviato. 403 dice che sa chi sei e la risposta è comunque no.

Un 401 deve includere l'header WWW-Authenticate?

Sì. RFC 9110 dice che un server che genera una risposta 401 deve inviare almeno un campo header WWW-Authenticate con una challenge, come Bearer per le API a token.

Un token scaduto deve ricevere 401 o 403?

401. Le credenziali non sono più valide, e delle nuove risolverebbero. Una challenge Bearer può indicarlo con error="invalid_token".

Posso restituire 404 invece di 403?

Sì. La specifica permette a un server di inviare 404 invece di 403 per nascondere se la risorsa esiste. È una scelta comune per gli id che appartengono ad altri utenti.

Un 403 significa che il mio indirizzo IP è bloccato?

Può darsi. I server inviano 403 per qualsiasi rifiuto che considerano definitivo per quella richiesta: regole sugli IP, permessi sui file mancanti, una regola del firewall o un controllo di ruolo fallito. Il corpo della risposta o il log del server di solito dice quale.

Due domande diverse

Ogni richiesta protetta risponde a due domande, in ordine. Chi sta chiamando? Questa è l'autenticazione, e se fallisce si ottiene 401. Questo chiamante può fare questa operazione? Questa è l'autorizzazione, e se fallisce si ottiene 403.
Tenerle separate aiuta i client. Un 401 dice al front end di mandare l'utente ad accedere. Un 403 gli dice che accedere di nuovo non servirà e che sullo schermo va invece un messaggio di accesso negato.

Cosa aggiunge la specifica

Quando una richiesta aveva già delle credenziali e riceve comunque un 401, il server sta dicendo che quelle credenziali sono state rifiutate. Per un 403 il server può spiegare il motivo nel corpo, oppure non dire nulla al riguardo.

Il controllo nel codice

Middleware Express: prima 401, poi 403

verifyToken sta al posto del tuo controllo di sessione o JWT. L'ordine conta: prima autentica, poi autorizza.

Front end: reagire in modo diverso a ciascuno

Un ramo del codice manda l'utente ad accedere; l'altro spiega il rifiuto.

Quale stato devo restituire?

Sì

La richiesta conteneva credenziali (cookie di sessione, token, header Authorization)?

Quelle credenziali erano valide e non scadute?

Questo chiamante può eseguire questa azione su questa risorsa?

Chi non ha accesso deve restare all'oscuro dell'esistenza della risorsa?

Invia questo

Nessuno ha effettuato l'accesso. Chiedi le credenziali con una challenge.

Le credenziali sono arrivate ma sono state rifiutate. Delle nuove risolverebbero.

Il chiamante è noto e non ha il permesso. Accedere di nuovo non servirà.

Il chiamante non ha il permesso e preferisci non rivelare che la risorsa esiste.