In de digitale wereld van vandaag is authenticatie een centraal onderdeel geworden van het beveiligen van websites en applicaties. OpenID Connect (OIDC), een authenticatielaag bovenop het OAuth 2.0-protocol, biedt een gestandaardiseerde en eenvoudige manier om identiteiten te authenticeren. Echter, het correct integreren van OIDC kan ontmoedigend zijn, vooral voor nieuwkomers. Een goed startpunt is vaak het OIDC-configuratiebestand, meestal te vinden op de `{authServerUrl}/.well-known/openid-configuration` URL, dat alle noodzakelijke details bevat voor het implementeren van OIDC-diensten. Deze gids is bedoeld om de belangrijkste velden binnen deze configuratie te verduidelijken, zodat ontwikkelaars hun belang en praktische toepassingen beter begrijpen om OIDC effectiever in hun projecten te integreren. ## Analyseren van OIDC-configuratievelden De OIDC-configuratie is een JSON-bestand vergelijkbaar met het volgende: ```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": "" } ``` Vervolgens zullen we dieper ingaan op enkele van de belangrijkste velden. ### authorization_endpoint Bij het integreren van OIDC-diensten omvat de eerste stap meestal het verwerken van inlogverzoeken van gebruikers binnen de applicatie. Dit proces omvat het omleiden van gebruikers naar het autorisatieserveradres `authorization_endpoint`. Dit endpoint is het serveradres waar autorisatieverzoeken worden verzonden, en begeleidt gebruikers naar de inlogpagina voor authenticatie. Bij het maken van een verzoek naar de `authorization_endpoint` moet het worden geconfigureerd met extra queryparameters voor elke autorisatie: - `response_type`: Geeft het type autorisatie aan dat wordt geretourneerd. Dit omvat meestal "code" (voor de autorisatiecode-stroom), "token" (voor de impliciete stroom), en "id_token token" of "code id_token" (voor de hybride stroom), die te vinden zijn in het `response_types_supported`-veld van de OIDC-configuratie. - `client_id`: Een unieke identificator die aan de applicatie is toegewezen door de autorisatieserver wanneer de app is geregistreerd. Deze ID wordt door de autorisatieserver gebruikt om de cliëntapplicatie die het verzoek initieert te herkennen. - `scope`: Definieert de gevraagde toegangsreikwijdte, specificeert de bronnen of gebruikersinformatie die toegankelijk is. Veelvoorkomende scopes zijn "openid" (verplicht), "profile", en "email", onder andere. U kunt de ondersteunde scopes vinden in het `scopes_supported`-veld van de OIDC-configuratie; verschillende scopes moeten worden gescheiden door spaties. - `redirect_uri`: Na inloggen of autorisatie leidt de autorisatieserver de gebruiker terug naar de URI die door de applicatie is opgegeven. Deze URI moet strikt overeenkomen met de URI die tijdens de registratie van de applicatie is opgegeven. - `state`: Een willekeurig gegenereerde string die wordt gebruikt om de cliënt te beschermen tegen cross-site request forgery-aanvallen. Consistentie van de state tussen het autorisatieverzoek en de callback moet worden behouden om de beveiliging te waarborgen. Deze parameters stellen ontwikkelaars in staat om het gedrag van OIDC-autorisatieverzoeken nauwkeurig te controleren, om te zorgen dat ze veilig zijn en aan de behoeften van de applicatie voldoen. ```js // Bouw de autorisatieverzoek-URL 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); // Redirect URI waarnaar de gebruiker wordt omgeleid na inloggen url.searchParams.append('redirect_uri', redirectUri); // Gevraagde toestemmingsreikwijdte, zoals "openid email profile" url.searchParams.append('scope', scope); // Een willekeurige state-waarde om CSRF-aanvallen te voorkomen url.searchParams.append('state', state); return url.toString(); } ``` Na het voltooien van het verzoek naar de `authorization_endpoint` en na authenticatie worden gebruikers omgeleid naar de gespecificeerde `redirect_uri`, die een zeer cruciale queryparameter zal bevatten—`code`. Deze autorisatiecode wordt verstrekt door de autorisatieserver en is het resultaat van de gebruiker die authenticatie en autorisatie geeft aan de app om toegang te krijgen tot hun informatie bij de autorisatieserver. ### token_endpoint `token_endpoint` is het serverendpoint dat door de autorisatieserver wordt gebruikt om de hierboven genoemde autorisatiecode om te wisselen voor toegangstokens en vernieuwings tokens. In de OAuth 2.0 autorisatiecode-stroom is deze stap cruciaal omdat het gaat om het omzetten van de verkregen autorisatiecode in feitelijke toegangstokens, welke de app kan gebruiken om toegang te krijgen tot de beschermde bronnen van de gebruiker. Hier is hoe de uitwisseling van de autorisatiecode voor toegangstokens wordt geïmplementeerd (merk op dat dit voorbeeld de `client_secret_post`-authenticatiemethode gebruikt. Voor andere ondersteunde authenticatiemethoden verwijzen we naar een nadere analyse van het `token_endpoint_auth_methods_supported`-veld): ```js // Wissel de autorisatiecode om voor toegangstokens 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(); } ``` In deze code sturen we eerst een verzoek naar de `token_endpoint` met behulp van de `POST`-methode. Het inhoudstype is ingesteld op `application/x-www-form-urlencoded`, wat vereist is door de meeste autorisatieservers. De aanvraagbody bevat de volgende parameters: - code: De autorisatiecode verkregen van de autorisatieserver, die wordt geretourneerd via de `redirectUri` nadat de gebruiker de autorisatie heeft voltooid. - redirect_uri: Dezelfde redirect URI die wordt gebruikt om de autorisatiecode te verkrijgen, gebruikt om de legitimiteit van het verzoek te verifiëren. - client_id: De cliëntidentificatie van de applicatie, gebruikt om de applicatie te identificeren die het verzoek maakt. - client_secret: Het cliëntgeheim van de applicatie, gebruikt om de identiteit van de applicatie te verifiëren. - grant_type: Geeft het type autorisatie aan, waarbij `"authorization_code"` hier wordt gebruikt, wat aangeeft dat het toegangstoken wordt verkregen via de autorisatiecode. Deze functie wordt asynchroon uitgevoerd en retourneert een JSON-object met het toegangstoken, wat de applicatie kan gebruiken om gebruikersgegevens op te vragen of andere operaties uit te voeren. ### userinfo_endpoint `userinfo_endpoint` is het serverendpoint dat door de autorisatieserver wordt gebruikt om gedetailleerde informatie over geauthenticeerde gebruikers te verkrijgen. Nadat gebruikers met succes hebben geautoriseerd en toegangstokens hebben verkregen via de `token_endpoint`, kan de applicatie dit endpoint opvragen om toegang te krijgen tot de gebruikersprofiel informatie, zoals gebruikersnaam en e-mailadres. De specifieke informatie die wordt verkregen, hangt af van de `scope` die door de gebruiker is opgegeven in het authenticatieverzoek. ```js // Haal gebruikersinformatie op async function fetchUserInfo(accessToken, tokenType) { const response = await fetch(config.userinfo_endpoint, { method: 'GET', // Roep userinfo_endpoint aan met behulp van de GET-methode headers: { /** * Gebruik het token-type en toegangstoken. * Het token-type dat wordt geretourneerd samen met het toegangstoken door de token-endpoint */ Authorization: `${tokenType} ${accessToken}`, }, }); if (!response.ok) { throw new Error('Het ophalen van gebruikersinformatie is mislukt.'); } return await response.json(); // Parseer en retourneer gebruikersinformatie in JSON-formaat } ``` In deze functie gebruiken we eerst de `GET`-methode om het `userinfo_endpoint` op te vragen, met inbegrip van het `Authorization`-veld in de verzoekheader, bestaande uit het `token_type` en `accessToken`. Dit is een standaard operatie volgens de OAuth 2.0-specificatie, om een veilige toegang tot gebruikersinformatie te waarborgen. Daarnaast is de scope van gebruikersinformatie die via het toegangstoken wordt benaderd volledig afhankelijk van de `scope`-parameterwaarden die door de gebruiker zijn aangenomen bij de autorisatieaanvang. Bijvoorbeeld, als de `email`-scope wordt gebruikt, zou de respons het e-mailadres van de gebruiker moeten bevatten. ### issuer & jwks_uri De issuer identificeert de URL van de autorisatieserver, terwijl de `jwks_uri` de URI biedt voor de JSON Web Key Set (JWKS), wat een set openbare sleutels is die worden gebruikt om JWT-handtekeningen te verifiëren. Het verifiëren van de JWT's `issuer` en handtekening zijn basisstappen in het waarborgen van tokenbeveiliging, maar in reële scenario's omvat het verificatieproces meestal ook het controleren van de geldigheidsperiode van het token, het publiek, de autorisatiescope, en andere belangrijke velden. De volgende code laat vooral zien hoe je de `issuer` en `jwks_uri` samen gebruikt om een JWT te verifiëren: ```js import { jwtVerify } from 'jose'; // Stel dat je de OIDC-configuratie hebt verkregen const config = { issuer: '', jwks_uri: '', }; // Haal JWKS op async function fetchJWKS() { const response = await fetch(config.jwks_uri); const { keys } = await response.json(); return keys; } // Valideer token async function validateToken(token, audience) { try { const jwks = await fetchJWKS(); const { payload } = await jwtVerify(token, jwks, { issuer: config.issuer, audience, }); console.log('Token succesvol gevalideerd:', payload); return true; } catch (error) { console.error('Token validatie mislukt:', error); return false; } } ``` ### scopes_supported & claims_supported De `claims_supported` en `scopes_supported`-velden verklaren de gebruikersattributen (claims) en toegangscopes (scopes) die door de autorisatieserver worden ondersteund. Ze helpen klanten te begrijpen welke gebruikersattributen en toegangscopes door de autorisatieserver worden ondersteund, waardoor klanten effectief autorisatieverzoeken kunnen construeren en responses kunnen parsen. Bij het construeren van een autorisatieverzoek kunnen cliënten de vereiste `scope` specificeren op basis van de behoeften van de applicatie. `Scope` definieert de middelen en handelingen waartoe de cliënt toegang vraagt, zoals `openid`, `email`, `profile`, en anderen. Het is belangrijk op te merken dat de specifieke claims die toegankelijk zijn in elk autorisatieverzoek variëren op basis van de scopewaarden die aan het begin van het authenticatieverzoek zijn gespecificeerd. Bijvoorbeeld, de email scope verleent toegang tot het e-mailadres van de gebruiker, terwijl de phone scope toegang geeft tot hun telefoonnummer. Daarom moeten cliënten zorgvuldig de relevante scope kiezen die past bij de behoeften van de applicatie bij het maken van een autorisatieverzoek, ervoor zorgend dat ze de noodzakelijke gebruikersattributen kunnen ophalen: ```js // Bouw de autorisatieverzoek-URL 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); // Specificeer de vereiste scope in het autorisatieverzoek url.searchParams.append('scope', scope); return url.toString(); } ``` ### token_endpoint_auth_methods_supported Het `token_endpoint_auth_methods_supported`-veld geeft de authenticatiemethoden aan die door het token-endpoint worden ondersteund. Deze methoden worden door de cliënt gebruikt om te authenticeren bij de autorisatieserver bij het inwisselen van de autorisatiecode voor toegangstokens. Bij het authenticeren met behulp van het token endpoint, zijn veelgebruikte authenticatiemethoden `client_secret_post`, `client_secret_basic` en `client_secret_jwt`. - `client_secret_post`: De cliënt gebruikt zijn cliënt-identificatie en cliëntgeheim om een form-encoded body te construeren, die als onderdeel van de aanvraagbody wordt verzonden. We hebben al een voorbeeld van deze methode gezien in de `token_endpoint`-sectie hierboven. - `client_secret_basic`: De cliënt gebruikt zijn cliënt-identificatie en cliëntgeheim om een basis authenticatieheader te construeren, die aan de aanvraagheader wordt toegevoegd. ```js // Gebruik de client_secret_basic-authenticatiemethode const headersBasic = new Headers(); headersBasic.append( 'Authorization', `Basic ${Buffer.from(`${clientId}:${clientSecret}`).toString('base64')}` ); // Stuur vervolgens het verzoek met de basis authenticatieheader om het toegangstoken te verkrijgen // ... ``` - `client_secret_jwt`: De cliënt gebruikt een JWT (JSON Web Token) als een cliëntassertie om zich te authenticeren. Deze JWT bevat de cliënt-identificatie en enkele extra metadata, en is ondertekend met behulp van het cliëntgeheim. Nadat de aanvraag is ontvangen, verifieert de autorisatieserver de identiteit van de cliënt door de handtekening van de JWT te verifiëren. ```js // Gebruik de client_secret_jwt-authenticatiemethode const clientSecretJwt = await new SignJWT({ iss: clientId, sub: clientId, aud: tokenEndpoint, jti: randomString(), exp: Math.floor(Date.now() / 1000) + 600, // Verlooptijd is 10 minuten iat: Math.floor(Date.now() / 1000), }) .setProtectedHeader({ alg: 'HS256', }) .sign(Buffer.from(clientSecret)); // Voeg de JWT-assertie toe aan de aanvraagbody const params = new URLSearchParams(); params.append('grant_type', 'authorization_code'); params.append('code', authorizationCode); // Voeg de cliëntassertieparameters toe params.append('client_assertion_type', 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer'); params.append('client_assertion', clientSecretJwt); // Stuur het verzoek en verkrijg het toegangstoken const tokenResponse = await fetch(tokenEndpoint, { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', }, body: params, }); ``` In praktische toepassingen moeten cliënten de juiste authenticatiemethode selecteren op basis van de methoden die door de autorisatieserver worden ondersteund, en ervoor zorgen dat de authenticatie-informatie correct aan het verzoek wordt toegevoegd om de autorisatiecode veilig om te wisselen voor toegangstokens. ## Samenvatting We hebben nu de belangrijkste velden in de OIDC-configuratie verkend, met een focus op hun doelstellingen en toepassingen. Het begrijpen van deze details zal je begrip van OpenID Connect verbeteren, waardoor je het effectiever in je projecten kunt integreren en gebruiken. Gewapend met deze kennis ben je beter uitgerust om het volledige potentieel van OIDC te benutten voor veiligere en efficiëntere gebruikersauthenticatieoplossingen. Logto als een authenticatieservice die is gebouwd op OIDC, biedt een uitgebreide reeks SDK's in verschillende talen samen met talrijke integratietutorials, waarmee je binnen enkele minuten naadloos OAuth / OIDC-aanmeldingen in je applicaties kunt integreren. Als je op zoek bent naar een betrouwbare en gebruiksvriendelijke OIDC-service, probeer dan vandaag nog Logto! Probeer Logto vandaag nog!