Vad är bearer-tokens?

Bakom nästan varje modern app-login eller API-förfrågan finns en tyst arbetsmyra: bearer-token. Du kanske inte märker det, men den finns där varje gång du kopplar samman tjänster, loggar in eller hämtar data från molnet.

Den här guiden går igenom vad bearer-tokens gör, varför de är viktiga och hur du hanterar dem säkert.

Vad är en bearer-token?#

En bearer-token är en databit, vanligtvis en teckensträng, som bevisar att innehavaren har tillstånd att komma åt en resurs. Det viktiga är att den som bär token kan använda den, utan att behöva lämna extra bevis.

Tänk på ett boardingkort för ett flygplan. När du har det i handen kan du gå igenom säkerhetskontrollen och gå ombord på planet. Ingen ber dig visa ID igen om boardingkortet är giltigt. På samma sätt låter en bearer-token din applikation "gå ombord på API:et" utan att behöva kontrollera din identitet varje gång.

Till exempel, efter att du loggat in på Spotify på din mobil, behöver du inte ange ditt lösenord varje gång du spelar en låt. Istället sparar appen en bearer-token som talar om för Spotifys servrar att "denna begäran kommer från en auktoriserad användare".

Hur bearer-tokens fungerar i praktiken#

Flödet för bearer-tokens kan delas upp i några steg:

1. Användaren loggar in

   Anta att du loggar in på en bankapp med ditt användarnamn och lösenord.

2. Identitetsleverantören utfärdar en token

   När du verifierats skickar autentiseringsservern tillbaka en bearer-token. Så här kan det se ut:

3. Klienten använder token

   Varje gång du trycker på "Visa saldo" eller "Överför pengar" inkluderar appen token i HTTP-begäran:

4. API:t validerar den

   Servern kontrollerar om token fortfarande är giltig, inte har gått ut och inkluderar rätt behörigheter (som read:balance eller write:transfer).

5. Åtkomst beviljas

   Om alla kontroller godkänns svarar servern med den begärda informationen.

Denna modell används brett i tjänster som GitHub API:er, där utvecklare autentiserar sig med en bearer-token istället för att upprepa sina inloggningsuppgifter.

Varför bearer-tokens blev populära#

Bearer-tokens blev populära eftersom de löste vanliga problem inom webbsäkerhet. Till skillnad från serverbaserade sessioner kräver de inte lagring av data för varje inloggad användare. Istället innehåller själva token tillräcklig information för att servern ska kunna validera begäran.

Till exempel, i en mikrotjänste-arkitektur, där dussintals tjänster kommunicerar med varandra, vore underhåll av central sessionslagring både komplext och ineffektivt. Med bearer-tokens kan varje tjänst självständigt validera förfrågningar och systemet blir mer lättviktigt och skalbart.

Ett konkret exempel: Slack’s API:er förlitar sig kraftigt på bearer-tokens. När du bygger en Slack-bot får du en token som låter din bot anropa Slack’s endpoints utan att behöva upprätta en session för varje användare.

Vad innehåller en bearer-token?#

Många bearer-tokens implementeras som JWT (JSON Web Tokens). Dessa tokens är kodade strängar som inkluderar information om användaren och deras behörigheter.

Låt oss avkoda ett exempel på en JWT:

Detta betyder:

• sub: Subjektet, eller användarens unika ID.
• name: Användarens namn.
• iat: Tidsstämpel då token utfärdades.
• exp: Utgångstid (när token blir ogiltig).
• scope: Behörigheterna, i detta fall tillåter appen både att läsa och skriva meddelanden.

I praktiken, om Janes token bara hade scope read:messages, skulle appen kunna hämta hennes meddelanden men inte skicka nya å hennes vägnar.

Bearer-tokens vs. access-tokens: Vad är skillnaden?#

Det är lätt att blanda ihop bearer-tokens och access-tokens eftersom termerna ofta förekommer tillsammans. Faktum är att de är relaterade men inte identiska.

Access-token: "Tillsåtelseslappen"#

En access-token är ett bevis på att en användare har behörighet att få tillgång till en resurs. Den bär information som:

• Vem användaren är (deras ID)
• Vad de får göra (scopes/behörigheter)
• När token går ut

Tänk på det som en tillståndslapp undertecknad av rektorn. Den berättar för läraren (API:t) att du får gå på skolutflykten (få tillgång till resursen).

Till exempel, när du loggar in på en molnlagrings-tjänst utfärdas en access-token med scope read:files. Den talar om för lagrings-API:t: "Den här användaren får läsa filer, men inte ta bort dem."

Bearer-token: "Överföringsformatet"#

En bearer-token är en typ av access-token. Ordet bearer beskriver hur token används: den som presenterar den kan "bära" den för att få tillgång till resurser, utan ytterligare identitetsbevis.

Med andra ord:

• Alla bearer-tokens är access-tokens.
• Men alla access-tokens måste inte vara bearer-tokens.

Det finns andra token-typer, som holder-of-key tokens, som kräver att klienten bevisar att den också har en kryptografisk nyckel utöver token. Bearer-tokens hoppar över det steget, vilket gör dem enklare men också mer riskfyllda om de blir stulna.

Exempel i praktiken#

• Access-token (allmän): Kan vara en signerad databit, ibland krävs att klienten bevisar innehav av en privat nyckel.
• Bearer-token (specifik): De flesta OAuth 2.0-implementeringar idag utfärdar access-tokens i bearer-format. Google OAuth ger t.ex. en access-token som används i Authorization: Bearer <token> headern.

Det betyder att när du ser "access-token" i OAuth-guider så är det nästan alltid en bearer-token om inget annat anges.

Jämförelse med andra token-typer#

För att göra bilden tydligare, såhär ser skillnaden ut mellan bearer-tokens och andra vanliga token-typer:

• Refresh-token: Används för att hämta en ny access-token när den gamla går ut. Refresh-tokens är vanligtvis inte bearer-tokens, då de utväxlas säkert med auktoriseringsservern och inte skickas direkt till API:er.
• ID-token: Används för autentisering, inte auktorisering. Den innehåller användaridentitet (t.ex. mejl, namn eller användar-ID). Beroende på systemet kan en ID-token också vara en bearer-token, men syftet skiljer sig från en access-token.
• API-nyckel: En enklare typ av autentisering som identifierar den anropande applikationen. Ofta fungerar API-nycklar som bearer-tokens då den som har nyckeln kan anropa API:t.

Bearer-tokens och access-tokens är inte motsättningar – de är relaterade:

• De flesta access-tokens är bearer-tokens.
• En bearer-token beskriver hur en token används (presenteras för åtkomst).
• I vardagligt tal används "access-token" och "bearer-token" ofta omväxlande, även om de tekniskt sett betonar olika aspekter.

Hur validera en JWT access-token (Bearer-token)#

Validering av en bearer-token är vad som står mellan ditt API och obehöriga användare. Om dina tokens är JWT:er sker valideringen lokalt och snabbt. API:t kan kontrollera token utan att fråga utgivaren varje gång.

Kärnan i valideringen#

1. Parsera token.
2. Verifiera signaturen med utgivarens publika nyckel.
3. Kontrollera vanliga claims som issuer, audience, expiry, not-before.
4. Verkställ dina app-regler som scopes, roller och token-typ.
5. Konsultera ev. revokationslistor eller sessionstillstånd för känsliga åtgärder.

Valideringschecklista (JWT)#

Använd detta som en körplan när du kopplar ett API-gateway eller middleware.

• Signatur

  Verifiera signaturen med den algoritm som anges i headern (t.ex. RS256). Hämta utgivarens JWKS-endpoint, välj nyckeln som matchar 'kid', och cacha den.

• Issuer (iss)

  Matcha token’s iss till din betrodda issuer-url, exakt och med rätt schema.

• Audience (aud)

  Kontrollera att token var avsedd för ditt API. Jämför med ditt API-id, t.ex. https://api.example.com eller en logisk audience-string.

• Expiration (exp) och Not-Before (nbf)

  Avvisa utgångna tokens. Respektera nbf så att en token inte kan användas innan sin starttid. Tillåt liten klockdifferens, vanligtvis 30 till 60 sekunder.

• Issued-At (iat)

  Användbart för felsökning och för att avvisa mycket gamla tokens i strikta upplägg.

• Token-typ

  Bekräfta att det är en access-token. Vissa leverantörer inkluderar typ: "at+jwt" eller liknande. Acceptera inte ID-tokens för API-åtkomst.

• Scopes / behörigheter

  Läs scope eller leverantörsspecifika claims (t.ex. permissions, roller). Verkställ minimal behörighet på varje endpoint.

• Subject (sub)

  Den stabila användar- eller klient-ID. Använd för att koppla resurser och för revision.

• Replay och revokering (valfritt men klokt)

  För känsliga endpoints, kontrollera en kortlivad svartlista av jti-värden, eller validera en aktiv sessionspost. Det hjälper efter utloggning eller misstänkt intrång.

Säkerhetsrisker med bearer-tokens#

Eftersom bearer-tokens innebär "den som har den kan använda den" måste de behandlas som husnycklar. Om någon stjäl din nyckel kan de låsa upp din dörr tills du byter lås.

Några vanliga risker är:

• Token-stöld – Om en hackare får tillgång till webbläsarens localStorage där token sparas kan den utge sig för att vara användaren. Exempelvis 2018 upptäcktes webbläsartillägg som stal tokens från localStorage och sålde dem.
• Replay-attacker – En angripare som får tag i en token kan återanvända den tills den går ut. Utan HTTPS är detta förvånansvärt enkelt.
• Långlivade tokens – Om en token är giltig i flera veckor eller månader ökar möjligheten för attacker.

Riktiga dataintrång har skett när utvecklare av misstag lagt upp bearer-tokens i öppna GitHub-repon. Angripare kan skanna efter dessa tokens och använda dem direkt för obehörig åtkomst.

Bästa praxis för användning av bearer-tokens#

För att använda bearer-tokens säkert är det viktigt att följa bästa praxis. Här kommer exempel på dessa:

1. Använd alltid HTTPS

   Tänk dig att skicka en token över ren HTTP på ett offentligt café-wifi. Vem som helst som lyssnar på nätverket kan kopiera token och logga in som du.

2. Använd kortlivade access-tokens

   De flesta plattformar delar ut tokens som går ut inom en timme. Googles OAuth-tokens varar t.ex. oftast en timme innan de kräver förnyelse.

3. Hantera refresh-tokens noggrant

   En refresh-token kan hämta nya access-tokens utan att användaren loggar in igen. Men den ska lagras säkert (till exempel krypterad i serverns databas), inte i klientens lagring.

4. Begränsa token’s behörigheter

   Om din app bara behöver läsa en användares kalender, be inte om write:calendar. Det minskar skadorna om token skulle bli stulen.

5. Återkalla tokens när det behövs

   Många SaaS-appar låter användare se aktiva sessioner och återkalla dem. GitHub låter dig till exempel återkalla personliga access-tokens när som helst.

6. Övervaka användning

   Loggning av token-användning kan avslöja misstänkt aktivitet. Om samma token plötsligt används i London och New York inom några minuter är det en varningssignal.

Bearer-tokens kontra andra autentiseringsmetoder#

Det är bra att jämföra bearer-tokens med andra vanliga metoder:

• Cookies & Sessioner

  Traditionella webbplatser förlitar sig på på serversparade sessioner identifierade via cookie. Detta passar bra för webbläsarappar men är mindre effektivt för API:er eller mobilappar. Facebooks inloggning på desktop använder t.ex. främst cookies, medan dess mobil-API:er använder tokens.

• API-nycklar

  En API-nyckel är en statisk sträng som autentiserar applikationen, inte användaren. En väderapp kan t.ex. använda en API-nyckel för att hämta data, men nyckeln säger inte till servern vilken användare som begär prognosen. Bearer-tokens kan bära användarspecifik data och är därför mer mångsidiga.

• Ömsesidig TLS (mTLS)

  Vissa högsäkerhetssystem använder certifikat på både klient och server. Det är säkrare men svårare att hantera i stor skala. För de flesta SaaS-plattformar ger bearer-tokens bra balans mellan användbarhet och säkerhet.

Viktiga slutsatser#

• Bearer-tokens är enkla men kraftfulla: den som har token kan komma åt resursen.
• De används brett inom OAuth 2.0 och OIDC-flöden, särskilt för API:er och mobilappar.
• Säkerhet beror på hanteringen: kort livslängd, scopes, HTTPS och återkallelse är viktigt.
• De är inte alltid det bästa valet, men för de flesta SaaS- och API-sammanhang ger de rätt balans mellan säkerhet och bekvämlighet.