OIDC sessionhantering

Vad är OIDC sessionhantering#

OpenID Connect (OIDC) är ett enkelt identitetslager byggt ovanpå OAuth 2.0-protokollet. Det gör det möjligt för klienter att verifiera slutanvändarens identitet baserat på autentiseringen utförd av auktorisationsservern, samt att få grundläggande profilinformation om slutanvändaren på ett interoperabelt och REST-liknande sätt.

OIDC är utformat för att vara enkelt att använda och implementera, med fokus på enkelhet och flexibilitet. Det används allmänt för enkel inloggning (SSO) och identitetsverifiering i webbapplikationer, mobilappar och API:er.

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

Denna artikel inkluderar flera nyckelbegrepp:

• Identity Provider (IdP): Tjänsten som lagrar och autentiserar användaridentiteter.
• Service Provider (SP) eller Relaying Party (RP): En webbtjänst som tillhandahåller tjänster till användare och förlitar sig på IdP för användarautentisering.
• Inloggningssession eller autentiseringssession: Den session som etableras när en användare loggar in på IdP.
• Beviljande: Den centraliserade användarautentiserings- och auktorisationsinformationen som genereras och hanteras av IdP.
• Single Sign-On (SSO): En sessions- 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 få tillgång till flera applikationer.

Hur fungerar OIDC autentiseringsflöde#

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

1. Användaren får tillgång till 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 existerar 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 in interaktionsresultatet till OIDC-leverantören.
6. OIDC-leverantören skapar en ny inloggningssession och autentiseringsbeviljande för användaren.
7. OIDC-leverantören omdirigerar användaren tillbaka till RP med en autentiseringskod (Authorizationskodflöde).
8. RP mottar autentiseringskoden och byter ut den mot tokens för att få tillgång till användarinformation.

Vad är RP inloggningssessionhantering#

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

En sessionskaka kommer att sättas säkert i användarens webbläsare för att bibehålla sessionsstatusen. Sessionskakan används för att identifiera användarens session och autentisera användaren för efterföljande autentiseringsförfrågningar. Denna kaka sätts vanligtvis med flaggorna HttpOnly och Secure för att förhindra klientsideåtkomst och säkerställa säker kommunikation.

En session för en enda RP#

För varje RP som användaren får tillgång till från olika enheter eller webbläsare, kommer en separat användarinloggningssession att etableras. Detta innebär att användarens autentiseringsstatus bibehå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 RPs#

Denna centraliserade sessionshantering tillåter också IdP att bibehålla ett konsekvent autentiseringstillstånd över flera RPs 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 få tillgång till flera RPs utan att behöva logga in igen.

Klientsideautentiseringsstatus#

I OIDC förlitar sig klientapplikationen (RP) på de tokens som utfärdats av IdP för att verifiera användarens identitet och autentiserings- eller auktorisationsstatus. "Inloggningssession" på klientsidan bibehålls av de tokens som utfärdats av IdP.

• ID-token: En kortlivad token som innehåller användarinformation och används för att verifiera den autentiserade användarens identitet.
• Åtkomsttoken: En token som ger åtkomst till skyddade resurser å användarens vägnar. Åtkomsttokenets livslängd kan vara kort eller lång, beroende på konfiguration. Klientapplikationer kan förlita sig på åtkomsttokenets giltighet för att bestämma användarens autentiseringsstatus. Om åtkomsttokenet har gått ut eller rensats kan användaren anses vara "utloggad" eller "icke-autentiserad" och behöver återautentiseras.
• Uppdateringstoken: Om offline_access-omfattningen efterfrågas och beviljas, kan klientapplikationen erhålla en uppdateringstoken. Det ger ett sätt att förlänga användarens autentiseringsstatus utan att kräva att användaren autentiseras igen. Klientapplikationen kan använda uppdateringstokenen för att få en ny åtkomsttoken när den nuvarande tillgångstokenet löper ut. Så länge uppdateringstokenen är giltig kan användarens autentiseringsstatus bibehållas utan behov av användarinteraktion.

Kombinationen av dessa tokens gör det möjligt för klientapplikationen att bibehålla användarens autentiseringsstatus och få åtkomst till skyddade resurser å användarens vägnar. Klientapplikationen behöver lagra dessa tokens säkert och hantera deras livscykel. (Till exempel för SPA-applikationer kan tokens lagras i webbläsarens lokala lagring eller sessionslagring. För webbapplikationer kan tokens lagras i server-side sessionsdata eller kakor.)

OIDC utloggningsmekanismer#

Utloggningsprocessen i OIDC är ett flerdimensionellt begrepp på grund av inblandningen av både centraliserade IdP-hanterade inloggningssessioner och distribuerade klientsidetokens.

Rensa tokens och lokala sessioner på klientsidan#

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

För webbapplikationer som hanterar sina egna användarinloggningssessioner kan ytterligare steg vara nödvändiga, inklusive att rensa sessionskakan och sessiondata (såsom tokens utfärdade av Identity Provider, eller IdP) för att säkerställa att användaren är helt utloggad.

Rensa centraliserade inloggningssession vid IdP#

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

För att fullt ut logga ut en användare från IdP, kan klientapplikationen (RP) initiera en utloggningsförfrågan till IdP. Applikationen (RP) bör omdirigera användaren till IdP:s end-session endpoint för att avbryta inloggningssessionen och rensa sessionskakor. Detta säkerställer en komplett utloggning över alla applikationer (RPs) som delar en och samma centraliserade session. När inloggningssessionen avslutats, och varje gång IdP mottar en tokenförfrågan från några länkade RPs som delar samma session, kommer IdP att uppmana användaren till återautentisering.

OIDC back-channel logout#

I vissa fall, när en användare loggar ut från en applikation (RP), kan de även vilja bli automatiskt utloggade från alla andra applikationer (RPs) utan ytterligare användarinteraktion. Detta kan åstadkommas med hjälp av back-channel logout-mekanismen.

När IdP tar emot en utloggningsförfrågan från en RP, kommer den inte bara att rensa inloggningssessionen utan också skicka en back-channel logout-notifikation till alla RPs som använder samma session och som har en registrerad back-channel logout endpoint.

När RPs mottar back-channel logout-notifikationen, kan de utföra nödvändiga åtgärder för att rensa användarens session och tokens, vilket säkerställer att användaren är fullständigt utloggad från alla applikationer.