Hybrid Flow med OIDC

Nøkkelen til Hybrid Flow ligger i parameteren `response_type`. I motsetning til `code` (Authorization Code Flow) eller `id_token token` (Implicit Flow) bruker Hybrid Flow kombinasjoner.

Vanlige verdier for `response_type` i Hybrid Flow inkluderer:

• code id_token
• code token
• code token id_token

Disse angir nøyaktig hvilke token Authorization Server skal returnere i svaret via front-channel.

Prosessen begynner på samme måte som i andre OIDC-flyter. Klientapplikasjonen omdirigerer brukerens nettleser til autorisasjonsendepunktet til Authorization Server.

Forespørselen inneholder parametere som:

• client_id: Identifikatoren til applikasjonen.
• redirect_uri: Hvor brukeren skal sendes tilbake.
• response_type: Viktig nok en hybrid kombinasjon (for eksempel code id_token).
• scope: Hvilke ressurser eller hvilken informasjon du vil ha tilgang til (for eksempel openid profile).
• nonce: En unik verdi som brukes én gang, for å redusere risikoen for replay-angrep.
• state: For å bevare tilstanden og forhindre CSRF-angrep.

Etter at brukeren har autentisert seg og gitt samtykke, omdirigerer Authorization Server brukerens nettleser tilbake til redirect_uri.

Omdirigerings-URL-en via front-channel vil inneholde både en autorisasjons-code og ett eller flere token (for eksempel id_token og access_token) direkte i URL-fragmentet eller spørringsstrengen, avhengig av response_type.

Med response_type=code id_token får du for eksempel begge.

Når omdirigeringen mottas, kan klientapplikasjonen (for eksempel en Single-Page Application) umiddelbart hente ut id_token fra URL-fragmentet.

Dette ID Tokenet kan brukes til å:

• Autentisere brukeren lokalt.
• Oppdatere brukergrensesnittet med profilinformasjon.
• Gi en følelse av umiddelbar innlogging uten flere nettverkskall.

code hentes også ut for senere bruk.

Autorisasjons-code som mottas i svaret via front-channel, brukes deretter av klientapplikasjonen til å sende en direkte, sikker forespørsel via back-channel til tokenendepunktet til Authorization Server.

Denne forespørselen, vanligvis fra backend-serveren eller en sikker klient, bytter code mot et nytt access_token og, ikke minst, et refresh_token.

Dette sikrer at refresh token aldri eksponeres i nettleseren.

Med Hybrid Flow kan du motta token fra to ulike kanaler: front-channel (ID Token og eventuelt Access Token) og back-channel (Access Token og Refresh Token).

Det er avgjørende å validere *alle* mottatte token for å sikre at de er ekte, intakte og gyldige. Dette omfatter kontroll av signaturer, utløpstidspunkt, målgruppe, utsteder og nonce for ID Token.

Hybrid Flow foretrekkes ofte for applikasjoner som trenger en rask og synlig innlogging (via ID Token i front-channel), men som også krever sikkerheten til et refresh token for langvarige økter (via kodeutveksling i back-channel).

• Fordeler: Umiddelbar brukeropplevelse og sikkerhet for refresh token.
• Ulemper: Mer komplisert å implementere og validere på grunn av flere token fra ulike kanaler.

Det balanserer brukeropplevelse med sterk sikkerhet ved henting av refresh token.

I dag utforsket vi OpenID Connect Hybrid Flow. Vi lærte hvordan den strategisk kombinerer elementer fra Authorization Code- og Implicit-flytene ved å bruke bestemte verdier for response_type.

Dette gjør det mulig for applikasjoner å hente identitetsinformasjon umiddelbart i nettleseren, samtidig som sikkerheten ved tokenutveksling via back-channel opprettholdes for refresh token. Det er et kraftig verktøy for fleksibel og sikker identitetsforvaltning.