Utforska OpenID Connect-konfiguration: Nyckelfält och deras användning

I dagens digitala värld har autentisering blivit en central komponent för att säkra webbplatser och applikationer. OpenID Connect (OIDC), ett autentiseringslager som bygger på OAuth 2.0-protokollet, erbjuder ett standardiserat och enkelt sätt att autentisera identiteter.

Men att integrera OIDC korrekt kan vara skrämmande, särskilt för nybörjare. En bra startpunkt är ofta OIDC-konfigurationsfilen, som vanligtvis finns på URL:en {authServerUrl}/.well-known/openid-configuration, och som innehåller alla nödvändiga detaljer för att implementera OIDC-tjänster.

Denna guide syftar till att klargöra de nyckelfält i denna konfiguration som hjälper utvecklare att förstå deras betydelse och praktiska tillämpningar för att bättre integrera OIDC i sina projekt.

Analysera OIDC-konfigurationsfält#

OIDC-konfigurationen är en JSON-fil som liknar följande:

Nästa avsnitt kommer att djupdyka i några av nyckelfälten.

authorization_endpoint#

När du integrerar OIDC-tjänster, innebär det första steget vanligtvis hantering av användarinloggningsförfrågningar inom applikationen. Denna process inbegriper att dirigera användare till auktorisationsserverns authorization_endpoint. Denna endpoint är serveradressen där auktorisationsförfrågningar skickas, och guidar användare till inloggningssidan för autentisering.

När du gör en förfrågan till authorization_endpoint, måste den konfigureras med ytterligare frågeparametrar för varje auktorisation:

• response_type: Anger typen av auktorisation som returneras. Detta inkluderar vanligtvis "code" (för auktoriseringskodflödet), "token" (för implicit flöde) och "id_token token" eller "code id_token" (för hybridflödet), vilket kan hittas i response_types_supported-fältet i OIDC-konfigurationen.
• client_id: En unik identifikator tilldelad till applikationen av auktoriseringsservern när appen registreras. Detta ID används av auktoriseringsservern för att känna igen klientapplikationen som initierar förfrågan.
• scope: Definierar det begärda åtkomstområdet och specificerar de resurser eller användarinformation som är åtkomliga. Vanliga scopes inkluderar "openid" (obligatoriskt), "profile" och "email", bland andra. Du kan hitta de stödda scope i OIDC-konfigurationens scopes_supported-fält; olika scopes bör separeras med mellanslag.
• redirect_uri: Efter inloggning eller auktorisation, omdirigerar auktoriseringsservern användaren tillbaka till URI:n som tillhandahålls av applikationen. Denna URI måste strikt matcha URI:n som tillhandahölls under applikationens registrering.
• state: En slumpmässigt genererad sträng används för att skydda klienten från tvärsårighetsattacker. Konsistens av staten mellan auktorisationsförfrågan och återkallning måste upprätthållas för att säkerställa säkerheten.

Dessa parametrar tillåter utvecklare att exakt kontrollera beteendet hos OIDC-auktorisationsförfrågningar, och säkerställa att de är säkra och uppfyller applikationens behov.

Efter att ha slutfört förfrågan till authorization_endpoint och genomgått autentisering, omdirigeras användare till den specificerade redirect_uri, vilken kommer att inkludera en mycket viktig frågeparameter—code. Denna auktoriseringskod tillhandahålls av auktoriseringsservern och är resultatet av att användaren autentiserar och godkänner appen att komma åt deras information på auktoriseringsservern.

token_endpoint#

token_endpoint är serverendpointen som används av auktoriseringsservern för att utbyta den ovan nämnda auktoriseringskoden mot åtkomst- och uppfriskningstokens. I OAuth 2.0 auktoriseringskodflöde är detta steg kritiskt eftersom det involverar konverteringen av den erhållna auktoriseringskoden till faktiska åtkomsttokens, som appen sedan kan använda för att åtkomma användarens skyddade resurser.

Så här implementeras utbytet av auktoriseringskoden mot åtkomsttokens (notera att detta exempel använder autentiseringsmetoden client_secret_post. För andra stödda autentiseringsmetoder, hänvisa till den senare analysen av

-fältet):

I denna kod skickar vi först en förfrågan till token_endpoint med metoden POST. Innehållstypen sätts till application/x-www-form-urlencoded, vilket krävs av de flesta auktoriseringsservrar. Förfrågningskroppen inkluderar följande parametrar:

• code: Auktoriseringskoden erhålls från auktoriseringsservern, vilken returneras via redirectUri efter att användaren slutför auktorisationen.
• redirect_uri: Samma omdirigerings-URI som användes för att erhålla auktoriseringskoden, används för att verifiera förfrågans legitimitet.
• client_id: Applikationens klientidentifierare, används för att identifiera applikationen som gör förfrågan.
• client_secret: Applikationens klienthemlighet, används för att verifiera applikationens identitet.
• grant_type: Anger typen av auktorisation, med värdet "authorization_code" här, vilket indikerar att åtkomsttoken erhålls genom auktoriseringskoden.

Denna funktion körs asynkront och returnerar ett JSON-objekt som innehåller åtkomsttoken, vilken applikationen kan använda för att begära användardata eller utföra andra operationer.

userinfo_endpoint#

userinfo_endpoint är serverendpointen som används av auktoriseringsservern för att få detaljerad information om autentiserade användare. Efter att användare framgångsrikt auktoriserar och erhållit åtkomsttokens genom token_endpoint, kan applikationen begära denna endpoint för att komma åt användarens profilinformation, såsom användarnamn och e-postadress. Den specifika informationen som erhålls beror på den scope som användaren angav i autentiseringsförfrågan.

I denna funktion använder vi först GET metoden för att begära userinfo_endpoint, inklusive Authorization fältet i förfrågningshuvudet sammansatt av token_type och accessToken. Detta är en standardoperation enligt OAuth 2.0-specifikationen, som säkerställer en säker hämtning av användarinformation. Dessutom beror omfattningen av användarinformation som nås via åtkomsttokenen helt på de scope parameter värden som användaren antar under auktorisationsinitiering. Till exempel, om email-scope används, bör svaret inkludera användarens e-postadress.

issuer & jwks_uri#

Issuer identifierar URL:en för auktoriseringsservern, medan jwks_uri tillhandahåller URI:n för JSON Web Key Set (JWKS), som är en uppsättning offentliga nycklar som används för att verifiera JWT-signaturer. Att verifiera JWT:s issuer och signatur är grundläggande steg för att säkerställa tokenens säkerhet, men i riktiga

scenarier innefattar verifieringsprocessen vanligtvis också kontroll av tokenens giltighetsperiod, publik, auktorisationsomfång och andra viktiga fält.

Följande kod demonstrerar huvudsakligen hur man använder issuer och jwks_uri tillsammans för att verifiera en JWT:

scopes_supported & claims_supported#

Fälten claims_supported och scopes_supported deklarerar användarattribut (claims) och åtkomstomfång (scopes) som stöds av auktoriseringsservern. De hjälper klienter att förstå vilka användarattribut och åtkomstomfång som stöds av auktoriseringsservern, möjliggör för klienter att effektivt konstruera auktorisationsförfrågningar och analysera svar.

När klienterna konstruerar en auktorisationsförfrågan kan de specificera det nödvändiga scope baserat på applikationens behov. Scope definierar resurser och operationer som klienten begär åtkomst till, såsom openid, email, profile och andra.

Det är viktigt att notera att de specifika claim som är åtkomliga i varje auktorisationsförfrågan varierar beroende på scope-värdena som specificeras i början av autentiseringsförfrågan. Till exempel, ger email-scope åtkomst till användarens e-postadress, medan phone-scope ger åtkomst till deras telefonnummer. Därför bör klienter noggrant välja relevant scope för att matcha applikationens behov när de skapar en auktorisationsförfrågan, och säkerställa att de kan hämta nödvändiga användarattribut:

token_endpoint_auth_methods_supported

#

Fältet

anger autentiseringsmetoderna som stöds av tokeninetoden. Dessa metoder används av klienten för att autentisera med auktoriseringsservern när de byter ut auktoriseringskoden mot åtkomsttokenen.

När du autentiserar med tokenendpointen, inkluderar vanliga autentiseringsmetoder client_secret_post, client_secret_basic och client_secret_jwt.

• client_secret_post: Klienten använder sitt klientidentifierare och sin klienthemlighet för att konstruera en formkodad kropp, som skickas som en del av förfrågningskroppen. Vi har redan sett ett exempel på denna metod i avsnittet token_endpoint ovan.

• client_secret_basic: Klienten använder sitt klientidentifierare och sin klienthemlighet för att konstruera en grundläggande autentiseringshuvud, som läggs till i förfrågningshuvudet.

• client_secret_jwt: Klienten använder en JWT (JSON Web Token) som en klientbevis för att autentisera. Denna JWT innehåller klientidentifieraren och viss ytterligare metadata och signeras med klienthemligheten. Efter att ha mottagit förfrågan verifierar auktoriseringsservern klientens identitet genom att validera JWT:s signatur.

I praktiska tillämpningar behöver klienter välja den lämpliga autentiseringsmetoden baserat på de metoder som stöds av auktoriseringsservern, och säkerställa att autentiseringsinformationen är korrekt tillagd i förfrågan för att säkert byta ut auktoriseringskoden mot åtkomsttokenen.

Sammanfattning#

Vi har nu utforskat de nyckelfälten in OIDC-konfigurationen, med fokus på deras syften och tillämpningar. Att förstå dessa detaljer kommer att förbättra din förståelse av OpenID Connect, vilket gör att du kan integrera och använda det mer effektivt i dina projekt. Med denna kunskap är du bättre rustad att utnyttja OIDC till fullo för mer säkra och effektiva användarautentiseringslösningar.

Logto som en autentiseringstjänst byggd på OIDC, som erbjuder en omfattande uppsättning SDK:er på olika språk tillsammans med många integrationstutorials, möjliggör för dig att sömlöst integrera OAuth / OIDC-loggar i dina applikationer på bara några minuter. Om du letar efter en pålitlig och lättanvänd OIDC-tjänst, ge Logto ett försök idag!