Implementera OIDC-utloggning och sessionshantering: En komplett guide

Vad är OIDC-sessionshantering#

OpenID Connect (OIDC) är ett enkelt identitetslager byggt på OAuth 2.0-protokollet. Det tillåter klienter att verifiera en slutanvändares identitet baserat på den autentisering som utförs av auktoriseringsservern, samt att få grundläggande profilinformation om slutanvändaren på ett interoperabelt och REST-liknande sätt.

OIDC är utformat för att vara lätt att använda och implementera, med fokus på enkelhet och flexibilitet. Det används ofta för single sign-on (SSO) och identitetsverifiering i webbapplikationer, mobilappar och API:er.

Att förstå autentiseringsstatus och sessionshantering inom OIDC är avgörande. Den här artikeln förklarar hur OIDC-sessioner och användarautentiseringsstatus hanteras i interaktioner mellan Identity Provider (IdP) och Relying Party (RP) eller Service Provider (SP).

Denna artikel inkluderar flera viktiga termer.

• Identity Provider (IdP): Tjänsten som lagrar och autentiserar användaridentiteter.
• Service Provider (SP) eller Relying Party (RP): En webbapplikation eller tjänst som tillhandahåller tjänster till användare och förlitar sig på IdP för användarautentisering.
• Inloggningssession eller Autentiseringssession: Sessionen som upprättas när en användare loggar in på IdP.
• Grant: Den centraliserade användarautentisering och auktoriseringsinformation som genereras och hanteras av IdP.
• Single Sign-On (SSO): En session och användarautentiseringstjänst som tillåter en användare att använda en uppsättning inloggningsuppgifter (t.ex. namn och lösenord) för att komma åt flera applikationer.

Hur fungerar OIDC-autentiseringsflödet#

För att bättre förstå OIDC-sessions- och användarautentiseringsstatushantering, låt oss kort granska OIDC-autentiseringsflödet för en webbapplikation:

1. Användaren går in på webbapplikationen (RP).
2. RP omdirigerar användaren till OIDC-leverantören (IdP) för autentisering.
3. OIDC-leverantören kontrollerar användarens inloggningssessionsstatus. Om ingen session finns eller om sessionen har gått ut uppmanas användaren att logga in.
4. Användaren interagerar med inloggningssidan för att bli autentiserad.
5. Inloggningssidan skickar interaktionsresultatet till OIDC-leverantören.
6. OIDC-leverantören skapar en ny inloggningssession och autentiseringsbeviljan för användaren.
7. OIDC-leverantören omdirigerar användaren tillbaka till RP med en autentiseringskod (Authorization Code flow).
8. RP tar emot autentiseringskoden och byter den mot tokens för att komma åt användarinformation.

Vad är RP-inloggningssessionshantering#

En inloggningssession upprättas när en användare loggar in på IdP. Denna session används för att spåra användarens autentiseringsstatus vid IdP. Sessionen innehåller vanligtvis information såsom användarens identitet, autentiseringstid och sessionens utgångstid. Den skapas när användaren först loggar in och underhålls tills användaren loggar ut eller sessionen går ut.

En sessionscookie kommer säkert att ställas in i användarens webbläsare för att upprätthålla sessionens tillstånd. Sessionscookien används för att identifiera användarens session och autentisera användaren för efterföljande autentiseringsförfrågningar. Denna cookie ställs vanligtvis in med flaggorna HttpOnly och Secure för att förhindra åtkomst på klientsidan och säkerställa säker kommunikation.

En session för enskild RP#

För varje RP som användaren kommer åt från olika enheter eller webbläsare kommer en separat användarinloggningssession att upprättas. Detta innebär att användarens autentiseringsstatus upprätthålls separat för varje RP. Om användaren loggar ut från en RP kommer användaren fortfarande att vara autentiserad vid andra RPs tills sessionen går ut eller användaren loggar ut från alla RPs.

Centraliserad session för flera RP#

Denna centraliserade sessionshantering tillåter också IdP att upprätthålla ett konsekvent autentiseringstillstånd över flera RP så länge användarens session är aktiv och autentiseringsförfrågningarna kommer från samma användaragent (enhet/webbläsare). Denna mekanism möjliggör SSO-funktioner, där användaren kan komma åt flera RP utan att behöva logga in igen.

Klientsidans autentiseringsstatus#

I OIDC förlitar sig klientapplikationen (RP) på de tokens som utfärdas av IdP för att verifiera användarens identitet och autentiserings- eller auktoriseringsstatus. "Inloggningssessionen" på klientsidan upprätthålls av de tokens som utfärdas av IdP.

• ID Token: En kortlivad token som innehåller användarinformation och används för att verifiera den autentiserade användarens identitet.
• Access Token: En token som ger tillgång till skyddade resurser på uppdrag av användaren. Livslängden för access token kan vara kort eller lång, beroende på konfigurationen. Klientapplikationer kan förlita sig på access tokenns giltighet för att bestämma användarens autentiseringsstatus. Om access token har gått ut eller rensats kan användaren betraktas som "utloggad" eller "oautentiserad" och behöver autentisera sig igen.
• Refresh Token: Om offline_access-scopen begärs och beviljas, kan klientapplikationen få en refresh token. Det ger ett sätt att förlänga användarens autentiseringsstatus utan att kräva att användaren autentiserar sig igen. Klientapplikationen kan använda refresh token för att få en ny access token när den nuvarande access token går ut. Så länge refresh token är giltig kan användarens autentiseringsstatus upprätthållas utan behov av användarinteraktion.

Kombinationen av dessa tokens tillåter klientapplikationen att upprätthålla användarens autentiseringsstatus och få åtkomst till skyddade resurser på uppdrag av användaren. Klientapplikationen behöver lagra dessa tokens säkert och hantera deras livscykel. (T.ex. För SPA-applikationer kan tokens lagras i webbläsarens lokala lagring eller sessionslagring. För webbapplikationer kan tokens lagras i serverns sessionsdata eller cookies.)

OIDC-utloggningsmekanismer#

Utloggningsprocessen i OIDC är ett mångfacetterat koncept på grund av involveringen av både centraliserade IdP-hanterade inloggningssessioner och distribuerade klientsidans tokens.

Rensa tokens och lokal session på klientsidan#

Att logga ut eller återkalla en användares autentiseringsstatus på klientsidan är relativt enkelt. Klientapplikationen kan ta bort lagrade tokens (ID token, access token och refresh token) från användarens webbläsare eller minne. Denna åtgärd gör effektivt användarens autentiseringsstatus ogiltig på klientsidan.

För webbapplikationer som hanterar sina egna användarinloggningssessioner kan ytterligare åtgärder vara nödvändiga. Dessa inkluderar att rensa sessionscookien och alla sessionsdata (såsom tokens utfärdade av Identity Provider, eller IdP) för att säkerställa att användaren loggas ut helt.

Rensa centraliserad inloggningssession vid IdP#

IdP upprätthåller en centraliserad inloggningssession för varje användare. Så länge denna session är aktiv kan användaren automatiskt bli autentiserad igen även om klientsidans tokens har rensats, vilket tillåter nya tokens att utfärdas till klientapplikationen utan att kräva ytterligare interaktion med IdP.

För att helt logga ut en användare från IdP kan klientapplikationen (RP) initiera en utloggningsbegäran till IdP. Applikationen (RP) bör omdirigera användaren till IdP:ns end-session endpoint för att avsluta inloggningssessionen och rensa sessionscookies. Detta säkerställer en fullständig utloggning över alla applikationer (RPs) som delar en samma centraliserad session. När inloggningssessionen har avslutats, när IdP tar emot en tokenbegäran från något länkat RP som delar samma session, kommer IdP att uppmana användaren att autentisera sig igen.

OIDC bakgrundskanal utloggning#

I vissa fall, när en användare loggar ut från en applikation (RP), kan de också vilja bli automatiskt utloggade från alla andra applikationer (RP) utan någon ytterligare användarinteraktion. Detta kan uppnås med bakgrundskanal utloggning mekanismen.

När IdP tar emot en utloggningsbegäran från en RP, rensar den inte bara inloggningssessionen utan skickar också en bakgrundskanal utloggningsmeddelande till alla RP som använder samma session och har en registrerad bakgrundskanal utloggning endpoint.

När RP tar emot bakgrundskanal utloggningsmeddelandet kan de utföra de nödvändiga åtgärderna för att rensa användarens session och tokens, vilket säkerställer att användaren är helt utloggad från alla applikationer.