OIDC-sessiebeheer

Wat is OIDC-sessiebeheer#

OpenID Connect (OIDC) is een eenvoudige identiteitslaag gebouwd bovenop 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, met een focus op eenvoud en flexibiliteit. Het wordt veel gebruikt voor Single Sign-On (SSO) en identiteitsverificatie in webapplicaties, mobiele apps en API's.

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

Dit artikel bevat verschillende belangrijke termen.

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

Hoe werkt de OIDC-authenticatiestroom#

Om het beheer van de OIDC-sessie en de gebruikerauthenticatiestatus beter te begrijpen, laten we kort de OIDC-authenticatiestroom voor een webapplicatie doornemen:

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 inlogsessie van de gebruiker. Als er geen sessie bestaat of de sessie is verlopen, wordt de gebruiker gevraagd om in te loggen.
4. De gebruiker werkt samen met de inlogpagina om geauthenticeerd te worden.
5. De inlogpagina dient het interactieresultaat in bij de OIDC-provider.
6. De OIDC-provider creëert een nieuwe inlogsessie 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 krijgen tot gebruikersinformatie.

Wat is RP-inlogsessiebeheer#

Een inlogsessie wordt ingesteld wanneer een gebruiker inlogt bij 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 sessieverlooptijd. Het wordt gecreëerd wanneer de gebruiker voor het eerst inlogt en wordt onderhouden totdat de gebruiker uitlogt of de sessie verloopt.

Een sessiecookie zal veilig worden 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 daaropvolgende authenticatieverzoeken. Deze cookie wordt doorgaans ingesteld met de HttpOnly en Secure-vlaggen om client-side toegang te voorkomen en een veilige communicatie te waarborgen.

Eén sessie voor één RP#

Voor elke RP waartoe de gebruiker toegang krijgt vanaf verschillende apparaten of browsers, zal een aparte gebruikersinlogsessie worden ingesteld. Dit betekent dat de authenticatiestatus van de gebruiker afzonderlijk wordt onderhouden voor elke RP. Als de gebruiker uitlogt bij een RP, blijft de gebruiker geauthentiseerd bij andere RPs totdat de sessie verloopt of de gebruiker uitlogt bij alle RPs.

Gecentraliseerde sessie voor meerdere RPs#

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

Authenticationstatus client-side#

In OIDC vertrouwt de clienttoepassing (RP) op de door de IdP uitgegeven tokens om de identiteit van de gebruiker en de authenticatie- of autorisatiestatus te verifiëren. De "inlogsessie" aan de clientzijde wordt onderhouden door de door de IdP uitgegeven tokens.

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

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

OIDC-uitlogmechanismen#

Het uitlogproces in OIDC is een veelzijdig concept vanwege de betrokkenheid van zowel gecentraliseerde IdP-beheerde inlogsessies als gedistribueerde client-side tokens.

Wis tokens en lokale sessie aan de clientzijde#

Uitloggen of de authenticatiestatus van een gebruiker intrekken aan de clientzijde is relatief eenvoudig. De clienttoepassing kan opgeslagen tokens (ID-token, toegangstoken en vernieuwingstoken) 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 gebruikersinlogsessies beheren, kunnen aanvullende 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 uitgelogd.

Wis gecentraliseerde inlogsessie bij de IdP#

De IdP onderhoudt een gecentraliseerde inlogsessie voor elke gebruiker. Zolang deze sessie actief is, kan de gebruiker automatisch opnieuw geauthenticeerd worden, zelfs als client-side tokens zijn gewist, waardoor nieuwe tokens kunnen worden uitgegeven aan de clienttoepassing zonder verdere interactie met de IdP.

Om een gebruiker volledig uit te loggen bij de IdP, kan de clienttoepassing (RP) een uitlogverzoek naar de IdP initiëren. De toepassing (RP) zou de gebruiker moeten omleiden naar het end-session endpoint van de IdP om de inlogsessie te beëindigen en sessiecookies te wissen. Dit zorgt voor een volledige uitlog over alle applicaties (RPs) die dezelfde gecentraliseerde sessie delen. Zodra de inlogsessie is beëindigd, zal de IdP de gebruiker vragen om opnieuw te authenticeren telkens wanneer de IdP een tokenverzoek krijgt van gekoppelde RPs die dezelfde sessie delen.

OIDC back-channel logout#

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

Wanneer de IdP een uitlogverzoek ontvangt van een RP, wist het niet alleen de inlogsessie, maar stuurt het ook een back-channel logoutmelding naar alle RPs die dezelfde sessie gebruiken en een geregistreerde back-channel logout endpoint hebben.

Wanneer de RPs de back-channel logoutmelding ontvangen, kunnen ze de nodige acties uitvoeren om de sessie en tokens van de gebruiker te wissen, zodat de gebruiker volledig is uitgelogd bij alle applicaties.