HTTP 401 Non autorizzato o 403 Proibito per un utente "disattivato"?

Question

Un servizio di autenticazione consente di disabilitare gli account utente (una sorta di soft-delete).

Se il server riceve una richiesta di autenticazione per un utente disabilitato che altrimenti sarebbe valido, il server dovrebbe restituire 401 o 403? Con entrambi i codici di stato, restituirei un messaggio che indica che l'account era stato disabilitato.

Per una rapida consultazione, le citazioni rilevanti HTTP/1.1 spec (sottolineatura mia):

401 non autorizzate

La richiesta richiede l'autenticazione dell'utente. La risposta DEVE includere un campo di intestazione WWW- autenticato (sezione 14.47) contenente una sfida applicabile alla risorsa richiesta. Il client PU MAY ripetere la richiesta con un campo di intestazione Autorizzazione adatto (sezione 14.8). Se la richiesta già inclusi credenziali di autorizzazione, allora la risposta 401 indica che autorizzazione è stata respinta per le credenziali di . Se la risposta 401 contiene la stessa sfida come la risposta prima , e l'agente utente ha già tentato l'autenticazione almeno una volta, quindi l'utente dovrebbe essere presentato il entità che è stato dato nella risposta, dal momento che entità potrebbe includere informazioni diagnostiche pertinenti. L'autenticazione di accesso HTTP è spiegata in "Autenticazione HTTP: Accesso di base e Digest Autenticazione" [43].

403 Forbidden

Il server capito la richiesta, ma si rifiuta di compierla. L'autorizzazione non aiuta e la richiesta NON DOVREBBE essere ripetuta. Se il metodo di richiesta non era HEAD e il server desidera rendere pubblico pubblico perché la richiesta non è stata soddisfatta, è DOVREBBE descrivere il motivo per il rifiuto nell'entità. Se il server non desidera che rendano disponibili queste informazioni al client, è possibile utilizzare il codice di stato 404 (non trovato).

Answer 1

Basato su an email scritto da Roy T. Fielding, apparentemente è a bug nella specifica HTTP corrente.

Il modo in cui la specifica è destinato da leggere è la seguente (usando citazioni da sopra e-mail):

401 "autenticato":

non si può fare questo perché non si è autenticato

403 "non autorizzato":

user agent inviato credenziali valide ma non dispone di accesso

Così, nel caso di un utente disabilitato, 403 è la risposta corretta (e 404 è anche un'opzione).

Answer 2

tecnicamente entrambi sono corretti, in realtà si riduce a quanto si vuole rivelare.

restituire un 401 dice al chiamante che l'account non è valido, che è corretto, ma se la tua API verrà quindi chiamata di nuovo per registrare un utente con le stesse credenziali, anche quella chiamata fallirebbe. che potrebbe non essere molto utile al chiamante.

quindi, dipende davvero da come verrà utilizzata la tua API e da chi/cosa è il pubblico di destinazione.

Answer 3

Ho due risposte diverse su cosa restituire in questo caso.

Scelta semantica - 401 Non autorizzato. In questo caso, il cliente ha fornito le credenziali e la richiesta è stata rifiutata in base alle credenziali specifiche. Se il cliente dovesse riprovare con un diverso insieme di credenziali, o se l'account dovesse essere riattivato in futuro, la stessa richiesta potrebbe avere successo.

Scelta di sicurezza - 404 Non trovato. Molti servizi restituiranno semplicemente un 404 per qualsiasi errore, al fine di evitare perdite di informazioni. Github mi viene in mente immediatamente.

Da General API Information, in docs sviluppatori di GitHub:

richieste non autenticate torneranno 404 per evitare qualsiasi tipo di perdita di informazioni private.

Per qualcosa che stavo distribuendo come servizio pubblico, probabilmente utilizzerei il 404 per evitare di fornire agli autori degli attacchi indizi sui loro tentativi di credenziali. Se fosse per consumo solo interno o in testing, probabilmente restituirei 401.