För mig blir OAuth 2.0 och OpenID Connect värdefullt först när resultatet går att testa med både positiva och negativa kontrollfall. OAuth 2.0 handlar om delegerad auktorisering medan OpenID Connect lägger ett identitetslager ovanpå; sammanblandning skapar ofta onödiga säkerhetsfel.
OAuth 2.0 och OpenID Connect i praktiken
Första byggstenen: Authorization code flow separerar användarens login från klientens tokenhantering. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: PKCE skyddar public clients mot stulna authorization codes. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Access tokens ska ha rätt audience och scope. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: ID token är till för klientens autentiseringskontext och bör inte behandlas som ett generellt API-token. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Arbetsgång utan genvägar
- Definiera resurser och scopes innan klienter registreras.
- Använd exakta redirect URIs.
- Kräv PKCE för klienter som inte kan skydda en client secret.
- Validera issuer, audience, signature och expiry.
- Håll access tokens kortlivade och begränsade.
För OAuth 2.0 och OpenID Connect håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Ett testbart exempel
Ett frontendprogram kan få användaren autentiserad korrekt men ändå begära ett alldeles för brett API-scope. Därför granskar jag identitet och resursbehörighet som två separata beslut.
När en bra idé blir fel i drift
- Att godkänna wildcard redirect URIs.
- Att skicka access tokens till fel API.
- Att använda ID token som auktoriseringsbevis för backend-resurser.
Efterkontroll
För OAuth 2.0 och OpenID Connect vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Fel redirect URI nekas.
- Token för audience A accepteras inte av API B.
- Scope utan rätt behörighet ger ett kontrollerat 403-svar.
Ett negativt test hör också till OAuth 2.0 och OpenID Connect: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
OAuth 2.0 och OpenID Connect – skilj auktorisering från autentisering handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.