HTTP-statuskod 401 eller 403? Hur autentiserings- och auktoriseringsfel skiljer sig

Varje gång du laddar en webbsida, gör en betalning eller loggar in i en app, sker en osynlig konversation mellan din enhet och en server. Det är lite som att skicka ett meddelande och vänta på ett svar—ibland är det en tummen upp, ibland en hövlig 'försök igen', och ibland ett bestämt 'nej'. Dessa svar, kända som HTTP-statuskoder, är internetets osjungna hjältar, som tyst styr kommunikationsflödet och ser till att allt flyter smidigt—eller åtminstone låter dig veta när det inte gör det.

Vad är HTTP-statuskoder#

HTTP-statuskoder är som signaler i en konversation mellan en klient (som din webbläsare eller app) och en server. De ger snabba och tydliga uppdateringar om vad som hände när du gjorde en begäran—om allt gick smidigt, något gick fel, eller om ytterligare åtgärder krävs. Låt oss tänka på det som att besöka ett välskött bageri:

200: Allt är perfekt#

Du ber om en croissant, och bagaren ler, räcker över den och säger, "Varsågod!". Det är en HTTP 200 OK—begäran lyckades, och allt fungerade som förväntat.

HTTP-statuskoden 200 OK är en av de mest använda koderna, vilket indikerar att begäran från klienten mottogs, förstås och behandlades framgångsrikt av servern.

301: Vi har flyttat#

Du anländer till ditt favoritbageri, men det finns en skylt som säger, "Vi har flyttat till 123 Nya Gatan.". Detta är en 301 Flyttad Permanent. Servern talar om för din webbläsare att automatiskt gå till den nya adressen.

HTTP-statuskoden 301 Flyttad Permanent indikerar att den begärda resursen har flyttats permanent till en ny URL. Denna statuskod informerar klienten (t.ex. en webbläsare eller API-klient) att uppdatera sina register och använda den nya URL:en för framtida förfrågningar.

404: Förlåt, det är inte här#

Du frågar efter en choklad scone, och bagaren säger, "Vi gör inte dem här." Det är en 404 Ej Hittad—resursen du letar efter finns inte på servern.

HTTP-statuskoden 404 Ej Hittad indikerar att servern inte kunde hitta den begärda resursen. Detta svar betyder att klientens begäran var giltig, men servern kunde inte hitta den resurs den ombads att hitta.

401: Vem är du?#

Du försöker komma in i VIP-loungen, men vakten stoppar dig och säger, "Du behöver visa ditt medlemskort." Det är en 401 Ej Auktoriserad—autentisering krävs innan du kan komma åt resursen.

HTTP-statuskoden 401 Ej Auktoriserad indikerar att klientens begäran inte har tillämpats eftersom den saknar giltiga autentiseringsuppgifter. Servern kräver att klienten autentiserar sig för att få åtkomst till den begärda resursen.

403: Inte för dig#

Du visar ditt medlemskort, men vakten säger, "Endast platinamedlemmar kan komma in." Det är en 403 Förbjudet—du är autentiserad men har inte de behörigheter som behövs för att få åtkomst till resursen.

HTTP-statuskoden 403 Förbjudet indikerar att servern förstår klientens begäran men vägrar att uppfylla den eftersom klienten inte har de nödvändiga behörigheterna. Detta skiljer sig från en 401 Ej Auktoriserad-status, eftersom klienten är autentiserad (eller begäran inte kräver autentisering), men åtkomst till resursen är uttryckligen nekad.

500: Ugnen står i brand#

Du gör en beställning, men plötsligt börjar rök strömma ut från köket. Bagaren säger, "Vi kan inte fullfölja din beställning; något gick fel internt." Det är en 500 Internt Serverfel—servern stötte på ett oväntat problem.

HTTP-statuskoden 500 Internt Serverfel indikerar att servern stötte på ett oväntat tillstånd som hindrade den från att uppfylla begäran. Det är ett generiskt felmeddelande och ger inga specifika detaljer om vad som gick fel.

503: Tillfälligt otillgänglig#

Du besöker bageriet, men det finns en skylt med "Stängt för underhåll". Bageriet kommer att öppna senare. Det är en 503 Tjänst Otillgänglig—servern är tillfälligt oförmögen att hantera din begäran, ofta på grund av överbelastning eller underhåll.

HTTP-statuskoden 503 Tjänst Otillgänglig indikerar att servern är tillfälligt oförmögen att hantera begäran. Detta kan bero på serveröverbelastning, underhåll eller andra tillfälliga förhållanden. Till skillnad från ett 500 Internt Serverfel innebär en 503 att problemet förväntas lösas snart.

HTTP-statuskoder är avgörande för att upprätthålla effektiv kommunikation mellan klienter och servrar. De informerar snabbt klienter om deras förfrågningar lyckades, misslyckades eller kräver ytterligare åtgärder. För utvecklare och IT-proffs är det viktigt att förstå dessa koder för felsökning, att designa bättre felhantering och förbättra användarupplevelsen.

Tänk på dem som professionella, standardiserade signaler i den pågående konversationen på internet.

I denna artikel vill jag fokusera på 401 och 403 fel, eftersom de är nära kopplade till autentisering (AuthN) och auktorisering (AuthZ).

När ska man använda 401 Ej Auktoriserad?#

HTTP-statuskoden 401 Ej Auktoriserad används när klientbegäran kräver autentisering, men den antingen saknas, är ogiltig eller har misslyckats. Den berättar för klienten att de behöver autentisera sig själva för att få tillgång till den begärda resursen. Förhållandet mellan autentisering och 401 Ej Auktoriserad-statuskoden ligger i autenticeringens roll för att avgöra huruvida en begäran kan fortsätta.

401 ej auktoriserad måste innehålla en WWW-Authenticate-rubrik, som ger detaljer om hur man autentiserar sig.

Så, vad är vanliga scenarier för att använda 401 Ej Auktoriserad?

1. Autentisering saknas

   Begäran inkluderar inte de nödvändiga autentiseringsuppgifterna. Till exempel: En begäran till en skyddad API-slutpunkt görs utan en Autoriseringsrubrik.

2. Ogiltiga autentiseringsuppgifter

   Klienten tillhandahåller referenser, men de är felaktiga eller matchar inte vad servern förväntar sig. Till exempel, en användare skickar en ogiltig API-nyckel eller en felaktigt formaterad token.

3. Utgången autentiseringstoken

   Autentiseringstoken är giltig men har gått ut, vilket kräver att klienten autentiserar om sig. Till exempel, en JWT-token med ett tidigare utgångsdatum (exp claim).

4. Saknad eller felaktigt formaterad autoriseringsrubrik

   Autoriseringsrubriken krävs men är antingen inte tillhandahållen eller felaktigt formaterad.

5. Autentiseringsschema stöds inte

   Servern stödjer inte klientens tillhandahållna autentiseringsmetod. Till exempel: Klienten skickar en Basic autentiseringsrubrik, men servern stödjer endast Bearer-tokens.

6. Ogiltig session eller tokenåterkallande

   Användarens session har blivit ogiltig eller deras token har blivit återkallad. Till exempel: En användare loggar ut, men samma token används för att komma åt en skyddad resurs.

Exempelsvar

När ska man använda 403 Förbjudet?#

HTTP-statuskoden 403 Förbjudet betyder att servern förstår begäran och klientens identitet (om autentiserad) men nekar åtkomst på grund av otillräckliga behörigheter. Den signalerar tydligt, "Du får inte göra detta," vilket säkerställer tydliga åtkomstgränser och förstärker säkerhetspolicyer.

Skillnaden mellan 401 Ej Auktoriserad och 403 Förbjuden ligger i deras roller inom autentiserings- och auktoriseringskontexter.

Auktorisering är en separat mekanism från autentisering. Medan autentisering identifierar vem du är, bestämmer auktorisering om du kan komma åt specifika resurser och vilka åtgärder du kan utföra på dem.

För att kolla in den detaljerade skillnaden om authN och authZ. Kolla in de följande artiklarna.

Vad är AuthZ

Vad är AuthN

Så vad är de vanliga scenarierna för att använda 403 Förbjudet?

1. Autentiserad men saknar behörighet

   Klienten är inloggad eller autentiserad men har inte nödvändiga behörigheter eller roll. Till exempel försöker en användare med "visnings"-rollen radera en fil, vilket kräver "redigerar"-behörigheter.

2. Resursåtkomst begränsad

   Åtkomst till resursen är avsiktligt begränsad till specifika användare eller grupper. Till exempel: Ett privat dokument som delats med specifika användare nås av någon som inte finns på åtkomstlistan.

3. IP- eller geografisk blockering

   Klientens IP-adress eller geografiska plats är blockerad av servern. Till exempel: En användare från en begränsad region försöker få åtkomst till en tjänst som bara fungerar i vissa länder.

4. Blockerade åtgärder av policy

   Klienten försöker göra en åtgärd som är förbjuden av server-sidopoliser eller regler. Till exempel: En användare försöker modifiera en resurs som är markerad som "endast läsbar".

5. Blockerade statiska resurser

   Servern nekar åtkomst till specifika statiska filer eller kataloger av säkerhetsskäl.

   Exempel: En användare försöker komma åt en .htaccess-fil eller serverns konfigurationsfil.

6. Konto avstängt eller inaktiverat

   Klientens konto är inaktiverat eller blockerat på grund av överträdelser eller inaktivitet. Till exempel: En användare med ett avstängt konto försöker logga in eller få åtkomst till resurser.

7. Åtgärden kräver höga behörigheter

   Den begärda åtgärden kräver speciella privilegier (t.ex. administratör eller superanvändare). Till exempel: En normal användare försöker få åtkomst till endast administratörsslutpunkter.

Exempelsvar:

Hur kan jag felsöka ett 401-auktofel#

Ett 401-fel indikerar typiskt att autentisering krävs och har misslyckats.

Kontrollera referenser#

Se till att Autoriseringsrubriken är närvarande och korrekt formaterad och verifiera att referenserna (API-nyckel, token eller lösenord) är korrekta och inte har gått ut. Att ange fel användarnamn eller lösenord är en av de vanligaste orsakerna till ett 401-fel.

Bekräfta autentiseringsmetod#

Servern kan förvänta sig en annan autentiseringsmetod än den som tillhandahålls. Detta kan ske om klienten och servern inte är i linje med autentiseringsprotokollet. Använd rätt metod (t.ex. Basic, Bearer, API-nyckel) enligt serverns specifikation och kontrollera rätt syntax i rubrikerna.

Granska serverns svar#

Titta igenom svarskroppen för felinformation och kontrollera WWW-Authenticate-rubriken för autentiseringsinstruktioner.

Verifiera begäran#

Bekräfta att slutpunkt, förfrågningsparametrar och värd är korrekta och se till att resursen du försöker komma åt kräver autentisering.

Kontrollera tokenproblem#

Dekoda och inspektera token (t.ex. med https://logto.io/jwt-decoder) för giltighet, utgång och krav och matcha tokens publik (aud) med API:ets krav.

Hur kan jag felsöka ett 403-förbjudet fel#

Ett 403 förbjudet fel betyder i allmänhet att godkännande processen slutfördes, men åtkomst nekades. För att felsöka detta fel, överväg följande förhållanden:

Bekräfta behörigheter#

Bekräfta att ditt konto, API-nyckel eller token har de nödvändiga behörigheterna för resursen. Kontrollera om resursen är begränsad till specifika roller eller grupper.

Se till att autentiseringen är korrekt#

Se till att du autentiserat dig korrekt (t.ex. med en giltig token eller referenser).

Kontrollera autentiseringsmetoden som krävs av servern.

Validera resurser#

Bekräfta att den begärda resursen finns och att du har tillgång till den. Om du använder API:er, verifiera slutpunkt krav i dokumentationen.

Kontrollera IP- eller platsbegränsningar#

Kontrollera om din IP-adress eller geografiska plats är begränsad av servern.

Granska serverns policyer#

Se till att den begärda åtgärden inte bryter mot serversidig regler eller policyer (t.ex. åtkomst till en endast läsbar resurs).

Inspektera serverns svar#

Granska svarskroppen för detaljer som förklarar orsaken till 403-felet.

Kan en enskild begäran returnera både 401 och 403-statuskoder samtidigt#

Nej, en enskild HTTP-begäran kan inte returnera både 401 Ej Auktoriserad och 403 Förbjuden statuskoder samtidigt eftersom ett HTTP-svar endast kan inkludera en statuskod.

Den praktiska användningen av 401 och 403 felkoder vid autentisering och auktorisering#

I modern applikationsutveckling är 401 Ej Auktoriserad och 403 Förbjuden två HTTP-statuskoder som utvecklare ofta stöter på. Även om de kan verka lika är deras betydelser och användningsfall tydligt olika. För att klargöra deras skillnader utforskar denna artikel praktiska exempel på dessa koder i scenarier som autentisering, auktorisering, multitenancy och multifaktorautentisering (MFA).

1. Inloggningsscenario: En användare försöker komma åt en skyddad sida utan att logga in eller tillhandahålla giltiga referenser. Servern svarar och kastar en 401 Ej Auktoriserad fel: "Du behöver logga in eller tillhandahålla giltiga referenser för att komma åt denna sida."
2. Åtkomstkontrollscenario: Samma användare loggar in framgångsrikt men försöker komma åt en endast administratörssida utan den nödvändiga administratörsrollen. Servern svarar och kastar en 403 Förbjuden: "Du är inloggad, men du har inte tillstånd att komma åt denna sida."
3. Multitenancy-scenario: Samma användare loggar in men tillhör Tenant A och försöker komma åt en resurs i Tenant B, där de inte har åtkomst. Servern svarar och kastar en 403 Förbjuden: "Du är autentiserad, men du har inte tillstånd att komma åt denna resurs i Tenant B."
4. MFA-scenario: En användare försöker logga in men har inte slutfört den nödvändiga multifaktorautentiseringen (MFA). Servern svarar och kastar en 401 Ej Auktoriserad fel: "Autentiseringen är inte klar. Vänligen slutför MFA för att fortsätta."

Att använda Logto som en autentisering och auktorisering leverantör#

Logto är främst en autentisering leverantör, som erbjuder viktiga metoder som lösenordslös inloggning, e-post och lösenord, MFA, Enterprise SSO och social inloggning, allt baserat på öppen-standardprotokoll som OIDC, OAuth 2.0 och SAML.

Logto Cloud erbjuder också viktiga auktoriseringen funktioner, inklusive Roll-baserad åtkomstkontroll (RBAC), Organisationer (Multi-Tenancy) och Anpassade Tokeninstanskrav för att möta en mängd olika auktoriseringsbehov.