Hybrid Flow met OIDC

De sleutel tot de hybride flow is de parameter `response_type`. In tegenstelling tot `code` (autorisatiecodestroom) of `id_token token` (impliciete stroom) gebruikt de hybride flow combinaties.

Veelgebruikte waarden voor `response_type` in de hybride flow zijn:

• code id_token
• code token
• code token id_token

Hiermee geef je de autorisatieserver precies aan welke tokens deze in de reactie via het frontchannel moet terugsturen.

Het proces begint net als bij andere OIDC-stromen. Je clienttoepassing stuurt de browser van de gebruiker door naar het autorisatie-eindpunt van de autorisatieserver.

Het verzoek bevat parameters zoals:

• client_id: De identificatie van je toepassing.
• redirect_uri: Waar de gebruiker naartoe wordt teruggestuurd.
• response_type: Cruciaal hierbij is een hybride combinatie (bijvoorbeeld code id_token).
• scope: Tot welke bronnen of informatie je toegang wilt (bijvoorbeeld openid profile).
• nonce: Een unieke waarde die maar één keer kan worden gebruikt om herhalingsaanvallen te beperken.
• state: Om de status te behouden en CSRF-aanvallen te voorkomen.

Nadat de gebruiker zich heeft geauthenticeerd en toestemming heeft gegeven, stuurt de autorisatieserver de browser van de gebruiker terug naar je redirect_uri.

Deze URL voor de omleiding via het frontchannel bevat zowel een autorisatie-code als een of meer tokens (bijvoorbeeld id_token en access_token) rechtstreeks in het URL-fragment of de queryreeks, afhankelijk van de response_type.

Bij response_type=code id_token ontvang je bijvoorbeeld beide.

Wanneer je clienttoepassing (bijvoorbeeld een toepassing met één pagina) de omleiding ontvangt, kan deze onmiddellijk het id_token uit het URL-fragment halen.

Dit ID-token kan worden gebruikt om:

• De gebruiker lokaal te authenticeren.
• De gebruikersinterface bij te werken met profielinformatie van de gebruiker.
• Een gevoel van onmiddellijk inloggen te geven zonder verdere netwerkaanroepen.

De code wordt ook uitgelezen voor later gebruik.

De autorisatie-code uit de reactie via het frontchannel wordt vervolgens door je clienttoepassing gebruikt om een rechtstreeks, veilig verzoek via het backchannel naar het token-eindpunt van de autorisatieserver te sturen.

Dit verzoek, meestal afkomstig van je backendserver of een beveiligde client, wisselt de code in voor een nieuw access_token en, belangrijker nog, een refresh_token.

Zo wordt voorkomen dat het vernieuwingstoken ooit in de browser terechtkomt.

Bij de hybride flow kun je tokens ontvangen via twee verschillende kanalen: het frontchannel (ID-token en mogelijk toegangstoken) en het backchannel (toegangstoken en vernieuwingstoken).

Het is essentieel om alle ontvangen tokens te valideren, zodat je hun authenticiteit, integriteit en geldigheid kunt vaststellen. Controleer daarbij onder andere handtekeningen, verloopdatum, doelgroep, uitgever en de nonce van ID-tokens.

De hybride flow heeft vaak de voorkeur voor toepassingen die snel zichtbaar moeten kunnen inloggen (via het ID-token in het frontchannel), maar ook de beveiliging van een vernieuwingstoken nodig hebben voor langdurige sessies (via de uitwisseling van de code in het backchannel).

• Voordelen: Directe gebruikerservaring en beveiliging van het vernieuwingstoken.
• Nadelen: Complexer om te implementeren en te valideren door de meerdere tokens uit verschillende kanalen.

De flow brengt een goede gebruikerservaring in evenwicht met sterke beveiliging bij het verkrijgen van vernieuwingstokens.

Vandaag hebben we de hybride flow van OpenID Connect verkend. We hebben geleerd hoe deze strategisch elementen van de autorisatiecodestroom en de impliciete stroom combineert door specifieke waarden voor response_type te gebruiken.

Zo kunnen toepassingen onmiddellijk identiteitsinformatie rechtstreeks in de browser ophalen, terwijl de beveiliging van tokenuitwisselingen via het backchannel voor vernieuwingstokens behouden blijft. Dit is een krachtig hulpmiddel voor flexibel en veilig identiteitsbeheer.