Vad är OIDC: Från varför vi behöver det till hur det fungerar

Definition av OpenID Connect (OIDC)#

OpenID Connect (OIDC) är ett identitetsautentiseringsprotokoll byggt ovanpå OAuth 2.0. Medan OAuth 2.0 endast tillhandahåller auktorisering, lägger OIDC till autentiseringsmöjligheter, vilket erbjuder en mer standardiserad lösning för användarauktorisering och autentiseringsscenarier.

Enkelt uttryckt: OIDC = Auktoriseringsprotokoll + Identitetsautentisering.

Varför behövs OIDC?#

För att förstå varför OIDC behövs, låt oss först utforska kärnkoncepten och arbetsflödet i OAuth 2.0, samt dess begränsningar i praktiska tillämpningar. Genom att analysera specifika scenarier ser vi varför vi behöver OIDC över OAuth 2.0.

Nyckelkoncept och auktoriseringsflöde av OAuth 2.0#

OAuth 2.0 (Open Authorization) är ett auktoriseringsprotokoll som låter användarna ge tredje parts applikationer tillgång till sina resurser utan att dela sina inloggningsuppgifter som användarnamn och lösenord. Det involverar fyra huvudroller:

• Resursägare: Användaren som äger resurserna
• Resursserver: Servern som lagrar användarresurser
• Klient: Tredjepartsapplikationen som begär åtkomst till användarresurser
• Auktorisationsserver: Servern som verifierar användaridentitet och utfärdar åtkomsttoken

Ett typiskt OAuth 2.0-auktoriseringsflöde fungerar så här:

Som visas hanterar OAuth 2.0 huvudsakligen utfärdandet av åtkomsttoken för tredjepartsklienter att få tillgång till användarresurser.

Begränsningen av OAuth 2.0#

OAuth 2.0-protokollet fokuserar endast på utfärdande av åtkomsttoken. Resursservern validerar dessa token och återger de auktoriserade resurserna. Resursservern känner dock inte till användarens identitet.

Detta var inte ett betydande problem i den tidiga internetmiljön.

Men när plattformar som Google, Facebook, Twitter och Github utvecklades började de erbjuda rika användarresurser som blev värdefulla för tredjepartsapplikationer.

Medan OAuth 2.0 är utmärkt för att auktorisera tredjepartstillgång till användarresurser, har det sina begränsningar. Ett vanligt scenario är: eftersom användarinformation också är en resurs, när tredjepartsapplikationer behöver tillgång till grundläggande användarinformation, återger olika plattformar (som Google, Facebook, Twitter) användarinformation i olika format, vilket skapar utmaningar för utvecklare.

OIDC skapades för att hantera dessa utmaningar.

Roller i OIDC#

För att möjliggöra användarautentisering ovanpå OAuth 2.0 och åtgärda dess begränsningar, introducerade OIDC tre roller:

• Slutanvändare (EU): Den slutliga användaren, motsvarande OAuth 2.0:s resursägare
• Betroende part (RP): Den beroende parten, motsvarande OAuth 2.0:s klient
• OpenID-leverantör (OP): Identitetsautentiseringstjänstleverantören, motsvarande OAuth 2.0:s auktorisationsserver och resursserver

OP är den centrala rollen, som tillhandahåller både OAuth 2.0:s auktoriseringsfunktionalitet och behandlar användarinformation som en separat resurs.

Hur fungerar OIDC?#

OIDC:s autentiseringsprocess liknar OAuth 2.0, men eftersom OP kombinerar rollerna som Auktorisationsserver och Resursserver, återger det både en åtkomsttoken och en ID-token. ID-token innehåller användarens identitetsinformation, och RP kan verifiera användarens identitet genom att validera ID-token.

Ett typiskt arbetsflöde ser ut så här:

Detta standardiserar hur användarinformation erhålls över olika plattformar och eliminerar behovet för tredjepartsapplikationer att hantera plattformsspecifika skillnader.

ID-token (identitetstoken) i OIDC#

När användare auktoriserar tredjepartsapplikationer, returnerar OP både en OAuth 2.0-åtkomsttoken och en JWT-format ID-token. Denna ID-token innehåller användarens identitetsinformation som användar-ID, användarnamn, e-post och avatar. RP kan bekräfta användarens identitet genom att validera ID-token.

Som en JWT innehåller ID-token standardiserade claims, inklusive dessa obligatoriska kärnclaims:

• iss (Utgivare): Unik identifierare för OpenID-leverantören som utfärdar ID-token
• sub (Ämne): Unik identifierare för användaren
• aud (Publik): Identifierare för klientapplikationen som mottar ID-token
• exp (Utgångstid): När ID-token går ut
• iat (Utfärdad vid): När ID-token utfärdades

För detaljerad information om ID-tokens, se: ID-token.

Userinfo endpoint#

UserInfo Endpoint är ett standardiserat HTTP API som tillhandahålls av OP för att få detaljer om autentiserade användare. Genom att skicka GET- eller POST-förfrågningar med en åtkomsttoken till denna endpoint kan du få användarinformation i JSON-format. Den returnerade datan inkluderar standardiserade fält som unikt användar-ID (sub), användarnamn (name), e-post och bild.

Processen för att skaffa userinfo följer samma mönster som att få åtkomst till skyddade resurser i OAuth 2.0. Vanligtvis är användarinformationen som erhålls från userinfo endpoint mer omfattande än vad som finns i ID-token, eftersom ID-token främst tjänar för identitetsautentisering och grundläggande användarinformation.

För detaljerad information om Userinfo endpoint, se: Userinfo endpoint.

Observera att den användarinformation du får från userinfo endpoint beror på de begärda scopes och behörigheter som beviljades under auktorisering.

Scopes i OIDC#

Scopes i OIDC definierar vilken användarinformation RP kan få tillgång till. OIDC definierar standardscope, med scopen openid som obligatorisk i OIDC-autentiseringsflöden.

Vanliga standardscope inkluderar:

• openid: Indikerar en OIDC-autentiseringsbegäran
• profile: Grundläggande användarinformation som namn och avatar
• email: Användarens e-postinformation
• phone: Användarens telefonnummer
• address: Användarens adressinformation

Olika scopes returnerar olika användarinformation. Till exempel, att begära openid profile email returnerar grundläggande användarinformation och e-post i ID-token och Userinfo, medan openid profile email phone address inkluderar telefonnummer och adressinformation också.

Identitetshantering baserad på OIDC#

OIDC är inte bara ett autentiseringsprotokoll; det är ett kraftfullt verktyg för att bygga flexibla, skalbara identitetshanteringssystem. Genom att lägga till ett autentiseringslager till OAuth 2.0, standardisera användarinformationsresurser, och lägga grunden för förlängda identitetshanteringsfunktioner, möjliggör OIDC olika identitetshanteringsscenarier:

• Single Sign-On (SSO): OIDC stödjer naturligt SSO genom förlängd användarsessionsinformation, vilket möjliggör enhetlig hantering av inloggningsstatus och delning av identiteter över applikationer
• Organisationstrukturshantering: Förlängd användarorganisationsinformation kan hantera komplexa organisationsstrukturer, inklusive avdelningshierarkier och användargruppsrelationer
• Behörighetshantering: Förlängda användarbehörighetsattribut möjliggör detaljerad kontroll av resursåtkomst, inklusive rollinformation och behörighetspolicykonfiguration

OIDC:s flexibilitet anpassar sig till föränderliga behov av identitetshantering. Många identitetshanteringssystem är byggda på OIDC, som Logto, som erbjuder SSO, organisationshantering och behörighetshanteringsfunktioner.