OAuth 2.0 och OIDC i produktion: Säker API-autentisering steg för steg

OAuth 2.0 är ett av de mest missförstådda protokollen i modern utveckling. Nästan alla använder det, få kan förklara skillnaden mot OpenID Connect, och de flesta säkerhetsbristerna jag hittar i API-integrationer bottnar i samma grundförväxling: att tro att OAuth handlar om inloggning. Det gör det inte. Den här guiden reder ut begreppen och går igenom hur man får det rätt i produktion, steg för steg.

Säker autentisering och auktorisering mellan system är en kärna i mitt arbete inom systemintegration, och det är ett område där genvägar straffar sig hårt.

Auktorisering är inte autentisering

Här ligger roten till nästan alla missförstånd. OAuth 2.0 är ett protokoll för auktorisering - det svarar på frågan "får den här appen göra det här åt den här användaren?". Det säger inget om vem användaren är. OpenID Connect, OIDC, är ett tunt lager ovanpå OAuth 2.0 som lägger till just identitet: vem användaren faktiskt är. OAuth ger en access token för att komma åt resurser; OIDC ger dessutom en id token som bevisar identitet. Använder ni OAuth för att "logga in" användare utan OIDC, gör ni sannolikt något subtilt fel - access token var aldrig tänkt att bevisa vem någon är.

Rätt flöde för rätt klient

OAuth definierar flera flöden, och valet beror på vilken sorts klient det handlar om. Det här är beslutet de flesta får om bakfoten.

• Authorization Code med PKCE är standarden för appar där en användare är inblandad - webbappar, mobilappar, SPA:er. PKCE är inte längre valfritt; det skyddar mot att en avlyssnad kod kan bytas in av fel part, och ska användas även för konfidentiella klienter.
• Client Credentials är flödet för maskin-till-maskin, där ingen användare finns - en bakgrundstjänst som pratar med ett API. Här finns ingen inloggning att tala om, bara en tjänst som bevisar sin egen identitet.
• Implicit flow och Resource Owner Password Credentials hör hemma i historieböckerna. Implicit är osäkert och utfasat till förmån för Authorization Code med PKCE, och att be om användarens lösenord direkt går emot hela poängen med OAuth. Ser jag dem i en ny integration är det en omedelbar varningsflagga.

Tokens: kortlivat, roterat och verifierat

Tokenhanteringen är där teori möter verklighet. Access tokens ska vara kortlivade - minuter, inte dagar - så att en läckt token snabbt blir värdelös. För längre sessioner används en refresh token för att hämta nya access tokens, och refresh tokens bör roteras vid varje användning så att en stulen token avslöjar sig när både angripare och legitim klient försöker använda samma.

Var dessa tokens lagras är minst lika viktigt. I en webbläsare hör de inte hemma i localStorage där vilket skript som helst kan läsa dem; httpOnly-cookies är en betydligt säkrare plats. Och tar ni emot en JWT som access token: verifiera den på riktigt. Kontrollera signaturen mot rätt nyckel, validera utfärdare och mottagare och att den inte gått ut. En JWT vars signatur ingen kontrollerar är inte säkerhet, det är dekoration.

Scopes, samtycke och minsta möjliga behörighet

Scopes avgränsar vad en token får göra. Principen om minsta möjliga behörighet gäller fullt ut: en integration som bara behöver läsa kalendrar ska inte be om skrivåtkomst till hela kontot. Överbreda scopes är både en säkerhetsrisk och en förtroendefråga gentemot användaren som ska godkänna åtkomsten. Be om det ni behöver, inte mer.

Vanliga fallgropar jag ser

De återkommande misstagen är förvånansvärt likartade: access tokens som lever för länge, tokens i localStorage, JWT:er som inte verifieras ordentligt, kvarvarande implicit flow, och scopes som är vidöppna "för säkerhets skull". Var och en är en känd brist med en känd lösning. Att gå igenom integrationen mot den här listan tar inte lång tid och fångar de flesta allvarliga hålen. Ett exempel på en sådan genomgång finns i kundcase, och hela arbetet kan jag göra med er inom systemintegration.

Relaterat

• API-first arkitektur: REST vs GraphQL vs gRPC vs tRPC beslutsguide
• Webhook-arkitektur som skalar: Retry, idempotens och dead letter queues
• GraphQL Federation: Microservices med ett enhetligt API-lager

Vill du ta det vidare?

Jag hjälper svenska bolag att få OAuth 2.0 och OIDC rätt i produktion - rätt flöde, kortlivade tokens och en säkerhetsgenomgång som fångar de vanliga hålen. Boka ett förutsättningslöst samtal.