JWT vs OAuth: Viktiga skillnader, hur de fungerar tillsammans och bästa praxis

Om du är ny inom autentisering och bygger en app som hanterar inloggningar, betalningar eller användardata har du antagligen stött på termerna JWT och OAuth. De kan låta som komplexa, "endast backend"-ämnen, men de är inte bara för säkerhetsingenjörer.

Med API:er, tredjepartsintegrationer och framväxande teknologier som AI, MCP och agentbaserade system, har dessa två en direkt roll i din produkts användbarhet, säkerhet och tillväxt. Att förstå grunderna innebär att du kan:

• Designa funktioner som är säkra från början
• Kommunicera effektivt med ditt engineeringteam
• Fatta bättre produktbeslut om autentisering och användarflöden
• Undvika kostsamma säkerhetsmisstag som förstör användarnas förtroende

Till exempel, i den senaste MCP-specifikationen, bygger auktoriseringssystemet på beprövade standarder:

• OAuth 2.1 IETF-utkast (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Authorization Server Metadata (RFC8414)
• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
• OAuth 2.0 Protected Resource Metadata (RFC9728)

Varför detta är viktigt#

Även om du aldrig skriver backend-kod:

• Utvecklare lär sig hur man säkrar API:er, hanterar sessioner och integrerar med tredjepartstjänster.
• Produktchefer får vokabulär för att diskutera inloggningsflöden, integrationer och efterlevnad med team och partners.
• Grundare och team i tidigt skede undviker att bygga sköra inloggningssystem som bryter vid integrationer eller lämnar dig öppen för intrång.

JWT vs OAuth: De två grundläggande koncepten#

JWT (JSON Web Token) och OAuth (Open Authorization) används ofta tillsammans, men de har olika syften.

Tänk på det så här:

• OAuth är hur du ger någon nycklarna, men bara till de rum de har tillträde till.
• JWT är ID-kortet de bär, bevis på vem de är och vad de kan göra.

I nästa avsnitt jämför vi dem sida vid sida så du tydligt ser skillnaderna och hur de kompletterar varandra.

Vad är OAuth 2.0?#

OAuth 2.0 är ett allmänt antaget auktoriseringsramverk som gör det möjligt för en applikation (klienten) att komma åt en användares resurser med begränsade behörigheter, utan att behöva dela användarens inloggningsuppgifter (som lösenord).

Kärnroller i OAuth#

• Klient: Applikationen som begär åtkomst.
• Ressursägare: Vanligtvis användaren, som ger tillstånd.
• Auktoriseringsserver: Utfärdar åtkomsttoken efter auktorisering.
• Resursserver: Värd för de skyddade resurserna och validerar tokens

Vanliga OAuth-granttyper (flöden)#

• Authorization Code Grant: Säkraste och rekommenderade, särskilt med PKCE för webbläsare, SPA och mobilappar.
• Implicit Grant: Numera avrått från i OAuth 2.1 av säkerhetsskäl.
• Resource Owner Password Credentials (ROPC): Byter direkt användarnamn och lösenord mot tokens; mindre säkert.
• Client Credentials Grant: För server-till-server- eller maskin-till-maskinkommunikation.
• Device Flow: För enheter utan tangentbord (t.ex. smarta TV-apparater), där användaren godkänner från en andra enhet.

Vad är JWT (JSON Web Token)?#

En JWT är en öppen standard (RFC 7519) för att säkert överföra påståenden mellan två parter på ett kompakt, URL-säkert sätt.

Struktur av en JWT#

En JWT består av tre base64url-kodade delar, separerade med punkter (.):

1. Header: Specificerar algoritmen (t.ex. HS256, RS256) och tokentyp (JWT).
2. Payload: Innehåller påståenden, såsom:
   • iss (utfärdare)
   • sub (ämne, t.ex. användar-ID)
   • aud (målgrupp)
   • exp (utgångstid)
   • Anpassade påståenden vid behov
3. Signatur – Verifierar att token inte blivit manipulerad.

Exempel:

Ett exempel på en JWT#

Här är ett exempel på en typisk JWT i dess kodade form, tillsammans med dess avkodade struktur så du ser vad varje del representerar.

Krypterad JWT (Base64URL)

Den består av tre delar separerade med punkter: header.payload.signature

Avkodad struktur

• Header

• Payload

Payloaden innehåller claims

• Signatur

Signaturen säkerställer att token inte blivit manipulerad.

Nyckelkaraktäristika#

• Självständig: All nödvändig information finns i token.
• Tillståndslös: Ingen serversidesession krävs.
• Signerad (och kan även vara krypterad) för att säkerställa äkthet.

JWT vs OAuth: Viktiga skillnader#

Kort sagt:

• JWT är behållaren: som ett pass med identitetsuppgifter.
• OAuth är systemet: som gränskontrollen, som avgör vem som får passet och vad de kan komma åt.

När ska du använda JWT ensamt?#

Använd endast JWT när:

• Autentisering för ett enda system där din app utfärdar och verifierar tokens utan extern identitetsleverantör.
• Tillståndslös sessionshantering för att validera användaridentitet utan serverlagring av sessioner.
• Enkel API-autentisering för interna API:er som endast kräver grundläggande åtkomstkontroll utan komplexa samtyckesflöden.
• Prestandafokuserad validering där resursservrar kan validera tokens lokalt utan att kontakta en auth-server.

Exempel:

En enkel-sidas app och backend-API som du äger. API:et utfärdar en JWT med sub (användar-ID), roll och exp (utgångstid)-påståenden.

När ska du använda endast OAuth?#

Använd OAuth utan JWT när:

• Du inte behöver självständiga tokens och att använda opaka tokens (som kräver uppslagning) är okej.
• Du vill att resursservern alltid kontrollerar med auktoriseringsservern innan åtkomst ges.
• Du är i en äldre eller reglerad miljö där JWT inte är lämpligt.
• Syftet är delegerad auktorisering för att säkert ge begränsad åtkomst till tredjepartsappar.

Exempel:

Ett API som utfärdar opaka åtkomsttoken och validerar varje förfrågan genom att fråga auktoriseringsservern.

När ska du använda både JWT och OAuth?#

Använd dem tillsammans när:

• Du har flera tjänster eller API:er och vill ha OAuth för säker flöde samt JWT för verifierbara tokens över tjänster.
• Du erbjuder tredjepartsinloggning som "Logga in med Google" där OAuth hanterar samtycke och JWT bär åtkomst- eller ID-token.
• Du har en mikrotjänstarkitektur där varje tjänst kan validera JWT lokalt.
• Du behöver skalbarhet med OAuth:s delegeringsmodell och JWT:s tillståndslösa verifiering.

Exempel:

Din app låter användare logga in med Google. OAuth hanterar auktorisationsprocessen, Google utfärdar en JWT-åtkomsttoken och dina API:er validerar den lokalt innan data returneras.

Hur JWT och OAuth fungerar tillsammans#

I moderna autentiserings- och auktoriseringsupplägg:

1. OAuth hanterar flödet för att ge åtkomst.
2. Auktoriseringsservern utfärdar en åtkomsttoken: ofta en JWT.
3. JWT skickas med API-förfrågningar för att bevisa identitet och rättigheter.

Särskilda token i OAuth#

• ID-token: Används i OpenID Connect för att bevisa användarens identitet; alltid en JWT.
• Access token: Kan vara en JWT eller opak token.

Bästa praxis för JWT och OAuth#

• Använd HTTPS för att skydda tokens under överföring.
• Sätt korta utgångstider för JWT; använd refresh tokens för längre sessioner.
  • https://auth.wiki/offline-access.
• Validera signaturen innan något påstående litas på.
• Kontrollera aud-claimen för att se att token är avsedd för din app.
• Undvik att lagra tokens i localStorage om XSS är en risk; använd hellre säkra cookies.

Slutliga tankar#

• OAuth 2.0 definierar hur man får och använder tokens.
• JWT definierar hur token ser ut och innehållsinformationen.
• De är kompletterande, inte utbytbara.

De flesta moderna API:er använder OAuth för auktoriseringsflöden och JWT för tokenrepresentation. Att förstå båda hjälper dig att designa säkra, skalbara autentiseringssystem.