Oversigt over OIDC-flows

Dette er det mest sikre og anbefalede forløb til OIDC, især for webapplikationer med en backend (fortrolige klienter).

• Sådan fungerer det: Klienten udveksler en autoriseringskode for tokens (ID Token og Access Token) direkte med OpenID-udbyderens token-slutpunkt.
• Denne udveksling foregår via en sikker forbindelse mellem servere (back-channel).

Autoriseringskodeforløbet foretrækkes, fordi tokens aldrig eksponeres i brugerens browser eller URL.

• Sikkerhed: Tokens udveksles direkte mellem servere, hvilket mindsker risikoen for opsnapning.
• Klienttype: Ideelt til webapplikationer med en backend.
• PKCE: Kombineres ofte med Proof Key for Code Exchange (PKCE) til offentlige klienter (for eksempel mobilapplikationer) for at forhindre opsnapning af koden.

Implicit-forløbet leverer tokens direkte til klienten via browserens URL-fragment efter brugerens autentifikation. Det blev tidligere brugt til enkeltsidesapplikationer (SPA'er).

Vigtigt: På grund af sikkerhedsproblemer, såsom lækage af tokens via browserhistorik eller henvisningsheadere, er Implicit-forløbet i vid udstrækning forældet ifølge OAuth2.0- og OIDC-specifikationerne.

Selv om det er enklere at implementere til browserbaserede applikationer, er dets sikkerhedsmæssige ulemper betydelige:

• Ingen kodeudveksling: Tokens tildeles direkte uden en sikker udveksling via back-channel.
• Eksponering via front-channel: Tokens vises i browserens URL, hvilket gør dem sårbare.
• Ingen fornyelsestokens: Dette forløb udsteder typisk ikke fornyelsestokens, så brugeren skal autentificeres igen.

Moderne SPA'er bør i stedet bruge Autoriseringskodeforløbet med PKCE.

Hybridforløbet kombinerer elementer fra både Autoriseringskodeforløbet og Implicit-forløbet. Det giver klienten mulighed for at modtage nogle tokens via front-channel (browseren) og andre via back-channel (server til server).

• For eksempel kan et ID Token returneres direkte i URL'en, mens et Access Token hentes via en kodeudveksling.

Dette flow giver fleksibilitet, men medfører øget kompleksitet og mulige sikkerhedsmæssige kompromiser, afhængigt af hvilke tokens der leveres via frontkanalen.

• Anvendelsesområder: Kan bruges, når en klient har brug for øjeblikkelig adgang til et ID-token (f.eks. til opdatering af brugergrænsefladen), men vil hente adgangstokenet på en mere sikker måde.
• Overvejelser: Vurder nøje sikkerhedskonsekvenserne ved tokens, der returneres direkte til browseren.

Når du vælger et OIDC-flow til din applikation, skal du altid prioritere sikkerheden:

• Webapps (fortrolige klienter): Brug Authorization Code-flowet med PKCE.
• Mobilapps/desktopapps (offentlige klienter): Brug Authorization Code-flowet med PKCE.
• SPA'er (offentlige klienter): Brug Authorization Code-flowet med PKCE.
• Implicit-flowet: Undgå at bruge det til nye applikationer på grund af sikkerhedsrisici.
• Hybrid-flowet: Brug det med forsigtighed og en klar forståelse af dets sikkerhedsmæssige konsekvenser.

Du har nu fået et overblik over de vigtigste OIDC-flows:

• Authorization Code-flowet: Det mest sikre flow, som anbefales til de fleste applikationer, især sammen med PKCE.
• Implicit-flowet: I vid udstrækning forældet på grund af sikkerhedsproblemer.
• Hybrid-flowet: En fleksibel, men mere kompleks mulighed, der kombinerer elementer fra begge.

Det er afgørende at forstå disse flows for at kunne implementere sikre identitetsløsninger. Nu går vi i dybden med implementeringen af specifikke OIDC-flows.