Cyber Security Academy · Lektion

OAuth 2.0-flöden

Auktoriseringsbeviljanden och token.

Lektion 1 av 413 steg

OAuth 2.0-flöden är en gratis lektion i Cyber Security Academy på CoddyKit. Detta är lektion 1 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Cyber Security Academy, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Cyber Security Academy innehåller totalt 4 lektioner.

Vad OAuth 2.0 faktiskt löser

OAuth 2.0 är ett ramverk för delegerad auktorisering. Det låter en användare ge en tredjepartsapplikation begränsad åtkomst till sina resurser på en annan tjänst utan att dela sitt lösenord.

Det handlar om auktorisering (vad en app får göra), inte autentisering (vem användaren är).
Appen får en åtkomsttoken med begränsat scope, aldrig användarens autentiseringsuppgifter.

Försvarare måste komma ihåg att OAuth i sig inte bevisar identitet. Att behandla en åtkomsttoken som bevis på inloggning är ett klassiskt misstag som OIDC hanterar.

De fyra rollerna

Varje OAuth-flöde omfattar fyra roller. Det är avgörande för hotmodelleringen att kartlägga dem korrekt.

Resursägare användaren som äger data.
Klient appen som begär åtkomst.
Auktoriseringsserver (AS) utfärdar token efter medgivande.
Resursserver (RS) API:t som lagrar skyddade data och validerar token.

Det finns förtroendegränser mellan dessa roller. En komprometterad klient eller en alltför tillåtande AS underminerar hela kedjan.

Roles:
  Resource Owner  -> grants consent
  Client          -> requests + uses tokens
  Authorization Server -> issues tokens
  Resource Server -> validates tokens

Auktoriseringskodflödet

Flödet Authorization Code är det rekommenderade flödet för webb- och mobilappar. Det skiljer användarens omdirigering från det hemliga tokenutbytet.

Användaren omdirigeras till AS för autentisering och medgivande.
AS returnerar en kortlivad code till den registrerade redirect URI:n.
Klienten byter server-till-server ut koden mot token via en bakkanal.

Eftersom token hämtas via bakkanalen visas de aldrig i webbläsarens adressfält eller historik.

GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &scope=read:profile
  &state=xyz

// then back-channel:
POST /token  grant_type=authorization_code&code=...

PKCE: Proof Key for Code Exchange

PKCE (RFC 7636) förstärker auktoriseringskodflödet och rekommenderas nu för alla klienter, även confidential clients.

Klienten genererar en slumpmässig code_verifier och skickar dess hash som code_challenge.
Vid tokenutbytet måste klienten presentera den ursprungliga verifieraren.

Det binder koden till den ursprungliga begäraren och hindrar en angripare som avlyssnar auktoriseringskoden från att lösa in den.

code_verifier  = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))

/authorize ... &code_challenge=...&code_challenge_method=S256
/token     ... &code_verifier=<original>

Client Credentials-flödet

Flödet Client Credentials används för åtkomst mellan maskiner när ingen användare är inblandad, till exempel när en backendtjänst anropar ett API.

Klienten autentiserar sig med sina egna autentiseringsuppgifter och får en åtkomsttoken.
Det finns normalt inget användarmedgivande och ingen refresh token.

Begränsa dessa token till så snäva scopes som möjligt och rotera klienthemligheter. Använd aldrig detta flöde för att utge er för slutanvändare.

POST /token
  grant_type=client_credentials
  client_id=service-a
  client_secret=***
  scope=orders:read

Access token kontra refresh token

OAuth utfärdar två huvudsakliga tokentyper med mycket olika livslängd och hanteringsregler.

Access token kortlivad och skickas till resursservern vid varje anrop. Behandla den som en bearer credential.
Refresh token långlivad och används endast mot AS för att hämta nya access tokens.

Refresh tokens är mycket värdefulla. Lagra dem säkert, bind dem till klienten och stöd återkallning.

POST /token
  grant_type=refresh_token
  refresh_token=<long-lived>
  client_id=app123

Bearer-token och överföring

De flesta OAuth-åtkomsttoken är bearer-token: den som har token kan använda den, ungefär som kontanter.

Överför dem alltid via TLS; aldrig i URL:er där de läcker till loggar och referrer-fält.
Skicka dem via Authorization-huvudet.
Överväg sender-constrained tokens (DPoP, mTLS) för API:er med hög risk.

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

// AVOID:
GET /api/data?access_token=...   // leaks in logs

Implicit Grant har fasats ut

Det äldre Implicit-grantet returnerade tokens direkt i fragmentet i redirect-URI:n. Det rekommenderas nu inte längre enligt OAuth 2.0 Security BCP och har tagits bort i OAuth 2.1.

Tokens läckte via webbläsarhistorik, referrer-headers och loggar.
Utan en back channel blev klientautentiseringen svagare.

Använd i stället Authorization Code with PKCE för SPA:er.

Parametern state och CSRF

Parametern state skyddar redirectsteget mot CSRF. Klienten genererar ett slumpmässigt värde, lagrar det i sessionen och verifierar det vid callbacken.

Avvisa svaret om det returnerade värdet för state inte stämmer.
Detta hindrar en angripare från att injicera sin egen auktoriseringskod i en offersession.

before:  session.state = randomNonce()
/authorize ... &state=<nonce>

on callback:
  if (req.state !== session.state) reject()

Scopes och minsta privilegium

Scopes anger hur detaljerad åtkomst en token ger. Tillämpa minsta privilegium i varje steg.

Begär endast de scopes som funktionen behöver (read:profile, inte admin).
Resursservrar måste kontrollera scope på varje endpoint, inte bara lita på att token är giltig.

Alltför långtgående samtycke är en vanlig risk i verkligheten: användare godkänner appar som ber om mycket mer åtkomst än vad som krävs.

Vanliga felkonfigurationer i OAuth

De flesta OAuth-incidenter beror på konfigurationen, inte på protokollet i sig.

Öppen omdirigering / lös matchning av redirect_uri gör det möjligt för angripare att stjäla koder.
Avsaknad av state eller PKCE möjliggör CSRF och kodinjektion.
Långlivade åtkomsttoken utan möjlighet till återkallning.
Att behandla en åtkomsttoken som ett autentiseringspåstående.

Registrera exakta redirect-URI:er och validera dem strikt.

redirect_uri allowlist:
  EXACT: https://app.example/cb
  NOT:   https://app.example/*  (too broad)

Snabbtest: säkra SPA-autentisering

Välj det korrekta, moderna flödet för scenariot nedan.

Besvara frågan i den interaktiva lektionen

Sammanfattning: OAuth 2.0-flöden

Viktiga slutsatser:

OAuth 2.0 är delegerad auktorisering, inte autentisering.
Det finns fyra roller: resursägare, klient, auktoriseringsserver och resursserver.
Authorization Code + PKCE är standardvalet för webb, mobil och SPA:er.
Client Credentials används för maskin-till-maskin-åtkomst.
Skydda lösningen med state, strikt matchning av redirect-URI:er, kortlivade åtkomsttoken och TLS överallt.
Implicit- och Password-grants har fasats ut.

Gratis att börja

Lär dig Cyber Security Academy med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser: 76
Lektioner: 303

Börja lära dig gratis Visa hela kursen

Vanliga frågor

Är lektionen ”OAuth 2.0-flöden” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Cyber Security Academy, inklusive ”OAuth 2.0-flöden”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Cyber Security Academy innehåller totalt 4 lektioner.

Vad lär jag mig i ”OAuth 2.0-flöden”?

Auktoriseringsbeviljanden och token. Ni övar på Cyber Security Academy med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Cyber Security Academy?

Du behöver inga förkunskaper. Utbildningen i Cyber Security Academy på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 1 av 4.

Hur lång tid tar lektionen ”OAuth 2.0-flöden”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Cyber Security Academy-lektionen?

Ja. Varje Cyber Security Academy-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

← Tillbaka till Cyber Security Academy