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: ```json { "authorization_endpoint": "", "claims_parameter_supported": false, "claims_supported": [ "sub", "name", "profile", "email", "email_verified", "phone_number", "phone_number_verified" ], "code_challenge_methods_supported": ["S256"], "grant_types_supported": [ "implicit", "authorization_code", "refresh_token", "client_credentials" ], "issuer": "", "jwks_uri": "", "response_modes_supported": ["form_post", "fragment", "query"], "response_types_supported": ["code id_token", "code", "id_token", "none"], "scopes_supported": ["openid", "offline_access", "profile", "email", "phone"], "subject_types_supported": ["public"], "token_endpoint_auth_methods_supported": [ "client_secret_basic", "client_secret_jwt", "client_secret_post" ], "token_endpoint_auth_signing_alg_values_supported": ["HS256"], "token_endpoint": "", "userinfo_endpoint": "" } ``` 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. ```js // Bygg URL:en för auktoriseringsförfrågan function createAuthRequestURL(clientId, redirectUri, scope, responseType, state) { const url = new URL(config.authorization_endpoint); url.searchParams.append('response_type', responseType); url.searchParams.append('client_id', clientId); // Omdirigerings-URI:n till vilken användaren omdirigeras efter inloggning url.searchParams.append('redirect_uri', redirectUri); // Begärt behörighetsområde, såsom "openid email profile" url.searchParams.append('scope', scope); // Ett slumpmässigt tillståndsvärde för att förhindra CSRF-attacker url.searchParams.append('state', state); return url.toString(); } ``` 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 `token_endpoint_auth_methods_supported`-fältet): ```js // Byt ut auktoriseringskoden mot åtkomsttokens async function fetchTokens(code, redirectUri, clientId, clientSecret) { const response = await fetch(config.token_endpoint, { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', }, body: `code=${code}&redirect_uri=${redirectUri}&client_id=${clientId}&client_secret=${clientSecret}&grant_type=authorization_code`, }); return await response.json(); } ``` 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. ```js // Hämta användarinformation async function fetchUserInfo(accessToken, tokenType) { const response = await fetch(config.userinfo_endpoint, { method: 'GET', // Anropa userinfo_endpoint med hjälp av GET-metoden headers: { /** * Använd tokentypen och åtkomsttoken. * Tokentypen returneras tillsammans med åtkomsttoken av tokenendpointen */ Authorization: `${tokenType} ${accessToken}`, }, }); if (!response.ok) { throw new Error('Misslyckades med att hämta användarinformation.'); } return await response.json(); // Analysera och returnera användarinformation i JSON-format } ``` 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: ```js import { jwtVerify } från 'jose'; // Anta att du har erhållit OIDC-konfigurationen const config = { issuer: '', jwks_uri: '', }; // Hämta JWKS async function fetchJWKS() { const response = await fetch(config.jwks_uri); const { keys } = await response.json(); return keys; } // Validera token async function validateToken(token, audience) { try { const jwks = await fetchJWKS(); const { payload } = await jwtVerify(token, jwks, { issuer: config.issuer, audience, }); console.log('Token validerades framgångsrikt:', payload); return true; } catch (error) { console.error('Misslyckades med att validera tokenen:', error); return false; } } ``` ### 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: ```js // Bygg URL:en för auktoriseringsförfrågan function createAuthRequestURL(clientId, redirectUri, scope, responseType) { const url = new URL(config.authorization_endpoint); url.searchParams.append('response_type', responseType); url.searchParams.append('client_id', clientId); url.searchParams.append('redirect_uri', redirectUri); // Specificera nödvändiga scope i auktorisationsförfrågan url.searchParams.append('scope', scope); return url.toString(); } ``` ### token_endpoint_auth_methods_supported Fältet `token_endpoint_auth_methods_supported` 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. ```js // Använd autentiseringsmetoden client_secret_basic const headersBasic = new Headers(); headersBasic.append( 'Authorization', `Basic ${Buffer.from(`${clientId}:${clientSecret}`).toString('base64')}` ); // Skicka sedan förfrågan med det grundläggande autentiseringshuvudet för att erhålla åtkomsttokenen // ... ``` - `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. ```js // Använd autentiseringsmetoden client_secret_jwt const clientSecretJwt = await new SignJWT({ iss: clientId, sub: clientId, aud: tokenEndpoint, jti: randomString(), exp: Math.floor(Date.now() / 1000) + 600, // Utgångstiden är 10 minuter iat: Math.floor(Date.now() / 1000), }) .setProtectedHeader({ alg: 'HS256', }) .sign(Buffer.from(clientSecret)); // Lägg till JWT-beviset i förfrågningskroppen const params = new URLSearchParams(); params.append('grant_type', 'authorization_code'); params.append('code', authorizationCode); // Lägg till klientbevisets parametrar params.append('client_assertion_type', 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer'); params.append('client_assertion', clientSecretJwt); // Skicka förfrågan och erhåll åtkomsttokenen const tokenResponse = await fetch(tokenEndpoint, { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', }, body: params, }); ``` 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! Pröva Logto idag!