401 vs 403: de juiste status voor een geweigerd verzoek

401 vs 403

401 vs 403: Unauthorized of Forbidden, en welke u teruggeeft | We.Inc

401 betekent niet geauthenticeerd, 403 betekent bekend maar niet toegestaan. Beantwoord vier vragen over een verzoek en krijg de juiste status, met headers en code.

Geef 401 Unauthorized terug als het verzoek geen geldige inloggegevens heeft: geen token, een verlopen sessie, een ongeldige handtekening. Inloggen kan het oplossen en de response moet een WWW-Authenticate-header bevatten. Geef 403 Forbidden terug als u weet wie de aanroeper is en die dit toch niet mag doen, zodat opnieuw inloggen niets verandert.

Unauthorized tegenover Forbidden

401 Unauthorized
403 Forbidden

Betekent eigenlijk
Niet geauthenticeerd
Niet toegestaan

Helpt inloggen?
Ja
Nee

Verplichte header
WWW-Authenticate
Geen verplicht

Typische oorzaak
Ontbrekende of verlopen token of sessie
Controle op rol of eigenaarschap mislukt

De client moet
Inloggen of de token vernieuwen en opnieuw proberen
Stoppen en een toegangsmelding tonen

Beantwoord vier vragen over het verzoek dat uw server weigert. De keuzehulp geeft de status die u moet sturen, de bijbehorende header en een reden van één regel die u in een codecommentaar kunt zetten. Hij behandelt ook het geval waarin u liever niet toegeeft dat de resource bestaat.

Geef aan of het verzoek überhaupt inloggegevens bevatte.
Geef aan of die inloggegevens klopten.
Geef aan of deze aanroeper toestemming heeft voor deze actie op deze resource.
Bepaal of het bestaan van de resource verborgen moet blijven voor aanroepers zonder toegang.

De naam Unauthorized is een historisch ongelukje. 401 gaat over authenticatie, wie u bent; 403 gaat over autorisatie, wat u mag doen.
Behandel in een single page app een 401 als signaal om de token te vernieuwen of het inlogscherm te tonen, en een 403 als een melding die de gebruiker niet kan oplossen door in te loggen.
Gebruik 404 in plaats van 403 voor privéresources waarvan het bestaan zelf gevoelig is, zoals het factuur-id van een andere klant.
Log 403's met het gebruikers-id en de permissie die faalde. Zo ziet u het snelst een rol die verkeerd is ingesteld.

Veelgestelde vragen

Wat is het belangrijkste verschil tussen 401 en 403?

401 zegt dat de server niet weet wie u bent, of het bewijs dat u stuurde niet accepteerde. 403 zegt dat hij weet wie u bent en dat het antwoord toch nee is.

Moet een 401 de WWW-Authenticate-header bevatten?

Ja. RFC 9110 zegt dat een server die een 401-response genereert ten minste één WWW-Authenticate-headerveld met een challenge moet sturen, zoals Bearer voor token-API's.

Krijgt een verlopen token een 401 of een 403?

401. De inloggegevens zijn niet meer geldig en nieuwe zouden het oplossen. Een Bearer-challenge kan dat aangeven met error="invalid_token".

Mag ik 404 teruggeven in plaats van 403?

Ja. De specificatie staat een server toe 404 te sturen in plaats van 403 om te verbergen of de resource bestaat. Dat is een gangbare keuze voor id's die bij andere gebruikers horen.

Betekent een 403 dat mijn IP-adres is geblokkeerd?

Dat kan. Servers sturen 403 bij elke weigering die ze voor dit verzoek als definitief beschouwen: IP-regels, ontbrekende bestandsrechten, een firewallregel of een mislukte rolcontrole. De body van de response of het serverlog zegt meestal welke.

Twee verschillende vragen

Elk beveiligd verzoek beantwoordt twee vragen op volgorde. Wie roept aan? Dat is authenticatie, en als die faalt volgt 401. Mag deze aanroeper dit doen? Dat is autorisatie, en als die faalt volgt 403.
Ze gescheiden houden helpt clients. Een 401 vertelt een front-end dat de gebruiker moet inloggen. Een 403 vertelt dat opnieuw inloggen niet helpt en dat er in plaats daarvan een toegangsmelding op het scherm hoort.

Wat de specificatie toevoegt

Als een verzoek al inloggegevens bevatte en toch een 401 krijgt, zegt de server dat die inloggegevens zijn geweigerd. Bij een 403 mag de server de reden in de body uitleggen, of er helemaal niets over zeggen.

De controle in code

Express-middleware: eerst 401, dan 403

verifyToken staat voor uw eigen sessie- of JWT-controle. De volgorde telt: eerst authenticeren, dan autoriseren.

Front-end: op elk anders reageren

Het ene codepad stuurt de gebruiker naar het inlogscherm; het andere legt de weigering uit.

Welke status moet ik teruggeven?

Nee

Bevatte het verzoek inloggegevens (sessiecookie, token, Authorization-header)?

Waren die inloggegevens geldig en niet verlopen?

Mag deze aanroeper deze actie op deze resource uitvoeren?

Moeten aanroepers zonder toegang niet te weten komen dat de resource bestaat?

Stuur dit

Niemand is ingelogd. Vraag om inloggegevens met een challenge.

Er kwamen inloggegevens binnen, maar ze werden afgewezen. Nieuwe zouden het oplossen.

De aanroeper is bekend en heeft geen toestemming. Opnieuw inloggen helpt niet.

De aanroeper heeft geen toestemming en u wilt liever niet onthullen dat de resource bestaat.