Implementatie van OIDC-afmelding en sessiebeheer: Een volledige gids

Wat is OIDC-sessiebeheer#

OpenID Connect (OIDC) is een eenvoudige identiteitslaag gebouwd op het OAuth 2.0-protocol. Het stelt clients in staat de identiteit van de eindgebruiker te verifiëren op basis van de authenticatie uitgevoerd door de autorisatieserver, evenals basisprofielinformatie over de eindgebruiker te verkrijgen op een interoperabele en REST-achtige manier.

OIDC is ontworpen om gemakkelijk te gebruiken en te implementeren te zijn, met de nadruk op eenvoud en flexibiliteit. Het wordt veelal gebruikt voor single sign-on (SSO) en identiteitsverificatie in webapplicaties, mobiele apps en APIs.

Begrip van authenticatiestatus en sessiebeheer in OIDC is cruciaal. Dit artikel legt uit hoe OIDC-sessies en gebruikersauthenticatiestatus worden beheerd in de context van interacties tussen de Identity Provider (IdP) en de Relying Party (RP) of Service Provider (SP).

Dit artikel bevat verschillende belangrijke termen.

• Identity Provider (IdP): De dienst die gebruikersidentiteiten opslaat en authenticeert.
• Service Provider (SP) of Relaying Party (RP): Een webapplicatie of dienst die diensten aan gebruikers verleent en vertrouwt op de IdP voor gebruikersauthenticatie.
• Aanmeldsessie of Authenticatiesessie: De sessie die wordt gevestigd wanneer een gebruiker inlogt op de IdP.
• Grant: De gecentraliseerde gebruikersauthenticatie- en autorisatie-informatie die wordt gegenereerd en beheerd door de IdP.
• Single Sign-On (SSO): Een sessie- en gebruikersauthenticatieservice die een gebruiker in staat stelt één set inloggegevens (bijv. naam en wachtwoord) te gebruiken om toegang te krijgen tot meerdere applicaties.

Hoe werkt de OIDC-authenticatiestroom#

Om een beter begrip te krijgen van OIDC-sessie en gebruikersauthenticatiestatusbeheer, laten we kort de OIDC-authenticatiestroom voor een webapplicatie herzien:

1. De gebruiker heeft toegang tot de webapplicatie (RP).
2. De RP leidt de gebruiker om naar de OIDC-provider (IdP) voor authenticatie.
3. De OIDC-provider controleert de status van de aanmeldsessie van de gebruiker. Als er geen sessie bestaat of de sessie is verlopen, wordt de gebruiker gevraagd om aan te melden.
4. De gebruiker interacteert met de aanmeldpagina om zich te authentiseren.
5. De aanmeldpagina dient het interactieresultaat in bij de OIDC-provider.
6. De OIDC-provider maakt een nieuwe aanmeldsessie en authenticatiegrant voor de gebruiker.
7. De OIDC-provider leidt de gebruiker terug naar de RP met een authenticatiecode (Authorization Code flow).
8. De RP ontvangt de authenticatiecode en wisselt deze in voor tokens om toegang te verkrijgen tot gebruikersinformatie.

Wat is RP-aanmeldsessiebeheer#

Een aanmeldsessie wordt vastgesteld wanneer een gebruiker inlogt op de IdP. Deze sessie wordt gebruikt om de authenticatiestatus van de gebruiker bij de IdP bij te houden. De sessie bevat doorgaans informatie zoals de identiteit van de gebruiker, authenticatietijd en sessievervaltijd. Het wordt gecreëerd wanneer de gebruiker voor het eerst inlogt en wordt onderhouden totdat de gebruiker uitlogt of de sessie verloopt.

Een sessiecookie wordt veilig ingesteld in de browser van de gebruiker om de sessiestatus te behouden. De sessiecookie wordt gebruikt om de sessie van de gebruiker te identificeren en de gebruiker te authentiseren voor volgende authenticatieverzoeken. Deze cookie wordt doorgaans ingesteld met de HttpOnly en Secure vlaggen om client-side toegang te voorkomen en veilige communicatie te garanderen.

Eén sessie voor één RP#

Voor elke RP die de gebruiker benadert vanaf verschillende apparaten of browsers, wordt een aparte gebruikersaanmeldsessie vastgesteld. Dit betekent dat de authenticatiestatus van de gebruiker afzonderlijk wordt onderhouden voor elke RP. Als de gebruiker uitlogt bij één RP, blijft de gebruiker nog steeds geauthentiseerd bij andere RPs totdat de sessie verloopt of de gebruiker bij alle RPs uitlogt.

Gecentraliseerde sessie voor meerdere RPs#

Dit gecentraliseerde sessiebeheer stelt de IdP ook in staat om een consistente authenticatiestatus te handhaven over meerdere RPs zolang de sessie van de gebruiker actief is en de authenticatieverzoeken afkomstig zijn van dezelfde user agent (apparaat/browser). Dit mechanisme maakt SSO-mogelijkheden mogelijk, waarbij de gebruiker toegang kan krijgen tot meerdere RPs zonder opnieuw in te hoeven loggen.

Client-side authenticatiestatus#

In OIDC vertrouwt de clientapplicatie (RP) op de door de IdP uitgegeven tokens om de identiteit van de gebruiker te verifiëren en de authenticatie- of autorisatiestatus te bepalen. De "aanmeldsessie" aan de client-side wordt onderhouden door de tokens die door de IdP zijn uitgegeven.

• ID Token: Een kortlevend token dat gebruikersinformatie bevat en wordt gebruikt om de identiteit van de geauthentiseerde gebruiker te verifiëren.
• Access Token: Een token dat toegang verleent tot beschermde bronnen namens de gebruiker. De levensduur van het access token kan kort of lang zijn, afhankelijk van de configuratie. Clientapplicaties kunnen vertrouwen op de geldigheid van het access token om de authenticatiestatus van de gebruiker te bepalen. Als het access token is verlopen of verwijderd, kan de gebruiker worden beschouwd als "uitgelogd" of "niet-geauthentiseerd" en moet hij opnieuw authenticeren.
• Refresh Token: Als de offline_access scope is aangevraagd en toegekend, kan de clientapplicatie een refresh token ontvangen. Het biedt een middel om de authenticatiestatus van de gebruiker te verlengen zonder dat de gebruiker opnieuw hoeft te authenticeren. De clientapplicatie kan het refresh token gebruiken om een nieuw access token te verkrijgen wanneer het huidige access token verloopt. Zolang het refresh token geldig is, kan de authenticatiestatus van de gebruiker worden gehandhaafd zonder dat gebruikersinteractie nodig is.

De combinatie van deze tokens stelt de clientapplicatie in staat om de authenticatiestatus van de gebruiker te behouden en toegang te krijgen tot beschermde bronnen namens de gebruiker. De clientapplicatie moet deze tokens veilig opslaan en hun levenscyclus beheren. (Bijv. Voor SPA-applicaties kunnen de tokens worden opgeslagen in de lokale opslag of sessieopslag van de browser. Voor webapplicaties kunnen de tokens worden opgeslagen in server-side sessiegegevens of cookies.)

OIDC-uitlogmechanismen#

Het afmeldproces in OIDC is een veelzijdig concept vanwege de betrokkenheid van zowel gecentraliseerde door de IdP beheerde aanmeldsessies als verspreide client-side tokens.

Wis tokens en lokale sessie aan de clientzijde#

Het afmelden of intrekken van de authenticatiestatus van een gebruiker aan de clientzijde is relatief eenvoudig. De clientapplicatie kan opgeslagen tokens (ID-token, access token en refresh token) uit de browser of het geheugen van de gebruiker verwijderen. Deze actie maakt effectief de authenticatiestatus van de gebruiker aan de clientzijde ongeldig.

Voor webapplicaties die hun eigen gebruikersaanmeldsessies beheren, kunnen extra stappen nodig zijn. Deze omvatten het wissen van de sessiecookie en eventuele sessiegegevens (zoals tokens uitgegeven door de Identity Provider, of IdP) om ervoor te zorgen dat de gebruiker volledig is afgemeld.

Wis gecentraliseerde aanmeldsessie bij de IdP#

De IdP onderhoudt een gecentraliseerde aanmeldsessie voor elke gebruiker. Zolang deze sessie actief is, kan de gebruiker mogelijk automatisch opnieuw worden geauthenticeerd, zelfs als client-side tokens zijn gewist, waardoor de clientapplicatie nieuwe tokens kan uitgeven zonder verdere interactie met de IdP.

Om een gebruiker volledig af te melden van de IdP, kan de clientapplicatie (RP) een afmeldverzoek indienen bij de IdP. De applicatie (RP) moet de gebruiker omleiden naar de einde-sessie-eindpunt van de IdP om de aanmeldsessie te beëindigen en sessiecookies te wissen. Dit zorgt voor een volledige afmelding over alle applicaties (RPs) die eenzelfde gecentraliseerde sessie delen. Zodra de aanmeldsessie is beëindigd, zal de IdP, wanneer deze een tokenverzoek ontvangt van aangemelde RPs die dezelfde sessie delen, de gebruiker vragen opnieuw te authenticeren.

OIDC-back-channel-logout#

In sommige gevallen, wanneer een gebruiker zich afmeldt bij één applicatie (RP), willen ze mogelijk ook automatisch worden afgemeld van alle andere applicaties (RPs) zonder enige extra gebruikersinteractie. Dit kan worden bereikt met behulp van het back-channel logout mechanisme.

Wanneer de IdP een afmeldverzoek van een RP ontvangt, wist deze niet alleen de aanmeldsessie, maar stuurt ook een back-channel-uitlogmelding naar alle RPs die dezelfde sessie gebruiken en een geregistreerd back-channel-uitlog-eindpunt hebben.

Wanneer de RPs de back-channel-uitlogmelding ontvangen, kunnen ze de noodzakelijke acties uitvoeren om de sessie en tokens van de gebruiker te wissen, zodat de gebruiker volledig is afgemeld van alle applicaties.