Verkent de belangrijkste velden en praktische toepassingen van de OpenID Connect-configuratie.
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.
De OIDC-configuratie is een JSON-bestand vergelijkbaar met het volgende:
Vervolgens zullen we dieper ingaan op enkele van de belangrijkste velden.
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.
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 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_supportedIn 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:
redirectUri nadat de gebruiker de autorisatie heeft voltooid."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 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.
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.
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:
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:
Het
token_endpoint_auth_methods_supportedBij 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.
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.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.
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!