FAGPORTALEN

OAuth 2.0 og JWT — autentifikation og autorisation

It A · STX · A-niveau · Netværk og protokoller

💻 OAuth 2.0 og JWT — autentifikation og autorisation

Autentifikation (authentication) = bevis på HVEM du er (login). Autorisation (authorization) = bevis på HVAD du må (rettigheder).

Klassisk session-baseret login: brugernavn + password → server tjekker DB → opretter session-ID → gemmer i cookie. Server slår session op ved hver request.

Problem: skalerer dårligt (server skal huske alle aktive sessions). OAuth 2.0 (2012, RFC 6749) = standard for autorisation mellem 3. parts apps. Bruges når 3. parts app skal have adgang til DINE data hos en service.

Klassisk eksempel: "Login med Google" på en ny app. App'en skal IKKE have din Google-password — kun en token til at læse din profil.

Aktører:

1. Resource Owner (du, brugeren).

2. Client (app'en der vil have adgang).

3. Authorization Server (Google, Facebook).

4. Resource Server (Google's API med dine data).

Flow — Authorization Code Grant (mest sikre):

1. App redirecter til Google's login-side med client_id + scope (fx email,profile).

2. Du logger ind + samtykker.

3. Google redirecter tilbage til app med code (kortlivet, ~10 min).

4. App's BACKEND udveksler code + client_secret → access_token (1 time) + refresh_token (lang levetid).

5. App bruger access_token i Authorization-header: Bearer eyJhbGc... ved API-kald.

Andre flows: Implicit (frarådet siden 2019), Client Credentials (server-til-server), Resource Owner Password (kun internt), Device Code (TV/IoT). OpenID Connect (OIDC, 2014) = identitet

Læringsmål

Sådan kan du arbejde med emnet

Arbejd iterativt med prototyper og dokumentation. Test, evaluér og dokumentér.

Øv dette emne med AI — quizzer, forklaringer og feedback tilpasset dit niveau.

Prøv Fagportalen gratis

🤖 Denne side er skrevet med kunstig intelligens og fagligt gennemgået af Fagportalen, som har det redaktionelle ansvar. Finder du en fejl, så skriv til support@fagportalen.dk.