Lär dig vad bearer-tokens är, hur de fungerar i OAuth 2.0 och JWT, skillnaden mot access-tokens och bästa praxis.
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.
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".
Flödet för bearer-tokens kan delas upp i några steg:
Användaren loggar in
Anta att du loggar in på en bankapp med ditt användarnamn och lösenord.
Identitetsleverantören utfärdar en token
När du verifierats skickar autentiseringsservern tillbaka en bearer-token. Så här kan det se ut:
Klienten använder token
Varje gång du trycker på "Visa saldo" eller "Överför pengar" inkluderar appen token i HTTP-begäran:
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).
Å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.
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.
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.
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.
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:
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."
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:
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.
<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.
För att göra bilden tydligare, såhär ser skillnaden ut mellan bearer-tokens och andra vanliga token-typer:
Bearer-tokens och access-tokens är inte motsättningar – de är relaterade:
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.
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.
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:
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.
För att använda bearer-tokens säkert är det viktigt att följa bästa praxis. Här kommer exempel på dessa:
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.
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.
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.
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.
Å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.
Ö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.
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.