## Introductie Het [OpenID Connect-protocol](https://openid.net/specs/openid-connect-core-1_0.html), ook wel OIDC genoemd, is uitgegroeid tot een veelgebruikte standaard voor het bieden van een fundamenteel raamwerk voor identiteitsbeheer. Het is een authenticatielaag die bovenop het bekende OAuth 2.0-protocol is gebouwd. Terwijl OAuth 2.0 alleen bedoeld is voor resource-autorisatie, is OIDC het protocol dat clientauthenticatie standaardiseert en versterkt, met behulp van het nieuw geïntroduceerde ID-token. Wacht... Misschien heb je gehoord van refresh tokens en toegangstokens in het OAuth-tijdperk, en nu komt er een nieuw concept in OIDC? Begrijp je echt de verschillen tussen deze tokens? [Logto](https://logto.io/), onze uitgebreide Customer Identity en Access Management (CIAM) oplossing, is gebouwd bovenop het OIDC-protocol. In onze gemeenschap is een van de meest gestelde vragen van onze gebruikers: > **Wat zijn de verschillen tussen een refresh token, een toegangstoken en een ID-token?** Dus in dit artikel zullen we ons verdiepen in de belangrijkste aspecten van OIDC-tokens, terwijl we ook laten zien hoe Logto de algehele ontwikkelaarservaring verbetert. Probeer Logto Cloud in 5 minuten ## Laten we beginnen met een praktisch scenario Stel je voor dat je werkt aan een typische client-server applicatie, en ze communiceren met elkaar via RESTful API's. Je wilt de meeste van je API's privé houden en alleen geautoriseerde clients toegang geven. Dan kom je misschien met de eerste vraag: ### Welk type token heb ik nodig om mijn API te beschermen? Het snelle antwoord is: Toegangstoken. In OIDC wordt elke beschermde API behandeld als een bron. Het toegangstoken is de daadwerkelijke inloggegevens die de client naar de server verzendt wanneer hij een API-bron opvraagt, meestal via de request-header. Aan de serverzijde, wanneer er een verzoek binnenkomt, hoeft de server alleen te controleren of het inkomende verzoek een geldig toegangstoken bevat. Een toegangstoken is een kortstondig toegangsbewijs dat autorisatie geeft om beschermde bronnen namens een gebruiker te benaderen. Wanneer een gebruiker zich met succes heeft geauthenticeerd met behulp van OIDC, geeft de autorisatieserver een toegangstoken uit. Dit token bevat informatie over de gebruiker, hun rechten en de duur van de geldigheid. Het token wordt vervolgens met elk volgend verzoek naar de resource-server gestuurd, zodat de server de identiteit van de gebruiker kan verifiëren en toegang tot de gewenste bronnen kan autoriseren. Maar je vraagt je misschien af: Als mijn clientapplicatie een geldig toegangstoken kan hebben na een succesvolle login, en het toegangstoken kan gebruiken om server-API's op te vragen, is dat dan niet voldoende? Waarom heb ik dan refresh tokens en ID-tokens nodig? Inderdaad, een geldige vraag, en laten we het stap voor stap uitleggen. ### Waarom hebben we refresh tokens nodig? Hoewel toegangstokens technisch gezien wel aan de minimale vereisten voldoen om het systeem te laten werken, is vanwege beveiligingsproblemen de geldigheid van toegangstokens meestal erg kort (meestal een uur). Dus stel je voor dat we alleen toegangstokens hebben, dan moeten de eindgebruikers zich elke keer opnieuw authenticeren wanneer het toegangstoken verloopt. Voor moderne single-page webapplicaties en vooral mobiele applicaties is het veelvuldig uitloggen een tamelijk pijnlijke gebruikerservaring, zelfs als we alleen maar hun gebruikersbeveiliging willen beschermen. Daarom hebben we een balans nodig tussen tokenbeveiliging en gebruikersgemak. Daarom introduceert OIDC refresh tokens. Een refresh token is een langer geldig token dat wordt gebruikt om nieuwe toegangstokens te verkrijgen zonder dat de gebruiker zich opnieuw hoeft te authenticeren. Het is als een sleutel om meer sleutels te krijgen. Refresh tokens worden gebruikt wanneer het toegangstoken verloopt of vernieuwd moet worden. Ze hebben een langere geldigheidsperiode vergeleken met toegangstokens en kunnen vaak dagen, weken of zelfs maanden geldig zijn. ### Waarom kunnen refresh tokens een langere levensduur hebben? Toegangstokens worden gebruikt om API-bronnen te benaderen, dus hun kortstondige aard helpt het risico van lekken of compromittering te verminderen. Aan de andere kant, aangezien refresh tokens alleen worden gebruikt voor het ruilen van nieuwe toegangstokens, worden ze minder vaak gebruikt dan toegangstokens, waardoor het risico op blootstelling wordt verminderd. Daarom wordt het aanvaardbaar geacht dat refresh tokens een langere geldigheidsperiode hebben. ### Waarborging van de beveiliging van refresh tokens Aangezien het refresh token ook aan de clientzijde wordt opgeslagen, is het waarborgen van hun niet-compromittering een uitdaging, vooral voor publieke clients zoals single-page webapplicaties (SPA). In Logto hebben refresh tokens een automatische [rotatiemechanisme](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13#section-4.12) dat standaard is ingeschakeld, wat betekent dat de autorisatieserver een nieuw refresh token uitgeeft zodra het aan de criteria voldoet: - Single-page applicaties: Herkend als clients zonder afzenderbeperkingen, vereisen deze apps refresh token-rotatie. De tijd-tot-leven (TTL) van het refresh token kan niet worden gespecificeerd. - Native apps en traditionele webapps: Refresh token-rotatie is inherent ingeschakeld, automatisch vernieuwend bij het bereiken van 70% van zijn TTL. [Meer informatie](https://docs.logto.io/docs/references/applications/#rotate-refresh-token) Hoewel je nog steeds de mogelijkheid hebt om refresh token-rotatie uit te schakelen op de pagina voor applicatiedetails in de beheersconsole, wordt sterk aanbevolen deze beschermingsmaatregel te behouden. ### De essentie van het ID-token [ID-token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) stelt de client in staat om basisgebruikersinformatie te verkrijgen zonder de server te hoeven vragen. Het ID-token is een nieuw tokentype dat door OIDC is geïntroduceerd en dat gecacheerde gebruikersauthenticatie-informatie bevat, waardoor de prestaties en eindgebruikerservaring worden verbeterd. In tegenstelling tot toegangstokens, die bedoeld zijn om alleen door de resource-server begrepen te worden, zijn ID-tokens klantvriendelijk. Wanneer de client een OIDC-tokenuitwisselingsverzoek doet, kan het een ID-token aanvragen samen met een toegangstoken. Het ID-token is een JSON Web Token (JWT) dat gebruikersclaims bevat zoals gebruikersnaam, e-mail, profielfoto, enz. Het is ondertekend door de autorisatieserver en kan door de client offline worden geverifieerd en gedecodeerd. Dit is vooral nuttig voor moderne single-page webapps en mobiele apps, waar de client het ID-token kan cachen en kan gebruiken om de authenticatiestatus van de gebruiker te bepalen, wat de algehele prestaties en gebruikerservaring aanzienlijk verbetert. Het is ook belangrijk op te merken dat ID-tokens niet worden gebruikt voor het autoriseren van toegang tot beschermde bronnen; toegangstokens vervullen die rol. In Logto gebruiken we ook ID-tokens in onze SDK's om de authenticatiestatus aan de clientzijde te helpen bepalen. Bijvoorbeeld in onze [JS SDK's](https://docs.logto.io/docs/references/applications/#rotate-refresh-token), kun je zien: ```tsx const isAuthenticated = Boolean(await this.getIdToken()); ``` Maar, zoals hierboven al vermeld, is de `isAuthenticated` vlag van de client-SDK slechts een client-cachestatus. De realtime authenticatiestatus moet nog steeds door de server worden bepaald, door het valideren van de refresh en toegangstokens. We bieden ook een `getUserClaims()` functie in onze SDK's om je te helpen het ID-token te decoderen en de gebruikersclaims te krijgen. Echter, de gecacheerde status wordt niet vernieuwd totdat de gebruiker zich opnieuw aanmeldt. Als je realtime gebruikersinformatie van de OIDC-server wilt ophalen, gebruik dan `fetchUserInfo()`. ## De voordelen en functies van Logto Logto is strikt gebouwd volgens het OIDC-protocol en biedt tegelijkertijd extra functies en voordelen voor ontwikkelaars en bedrijven: 1. Handige SDK's: Logto SDK's stroomlijnen tokenbeheer voor jou. Je hoeft je refresh token en toegangstoken niet handmatig op te slaan. Roep gewoon `getAccessToken()` elke keer op en de SDK zal altijd proberen het opgeslagen toegangstoken opnieuw te gebruiken, of het automatisch vernieuwen als het verlopen is. 2. Refresh token-rotatie: Logto handhaaft een mechanisme voor rotatie van refresh tokens om ervoor te zorgen dat je refresh token altijd wordt vernieuwd nadat het is gebruikt, wat het risico van lekken of compromittering vermindert. Hoewel je het nog steeds kunt uitschakelen in de beheersconsole, wordt het sterk aanbevolen om het ingeschakeld te houden. 3. Geoptimaliseerde prestaties: Met behulp van ID-tokens kun je altijd basisgebruikersinformatie krijgen zonder de server te vragen. Maak gebruik van de `isAuthenticated` status en `getIdTokenClaims()` functie die door de Logto SDK's wordt verstrekt om de gebruikersauthenticatiestatus te controleren en gebruikersclaims aan de clientzijde te decoderen. 4. Verbeterde beveiliging: Logto handhaaft veilige verbindingen tussen de client en de autorisatieserver met behulp van HTTPS en TLS. Dit beschermt je tokens tegen mogelijke diefstal door ongeautoriseerde derden en garandeert de beveiliging van je systeem. ## Conclusie In het OIDC-protocol werken Refresh Tokens, Toegangstokens en ID-Tokens samen om veilige en naadloze gebruikersauthenticatie te bieden. - Refresh tokens elimineren gebruikersinterventie voor nieuwe toegangstokens. - Toegangstokens bieden autorisatie om beschermde bronnen te benaderen. - ID-tokens bieden gecacheerde gebruikersinformatie aan de cliënt, wat de prestaties verbetert. Het begrijpen van de rol en betekenis van deze tokens is cruciaal voor ontwikkelaars die OIDC-authenticatie in hun toepassingen implementeren. Door voor Logto te kiezen, kunnen ontwikkelaars en bedrijven het volledige potentieel van dergelijke OIDC-functies ontgrendelen, robuuste en veilige authenticatiesystemen integreren die gebruikersgegevens beschermen en een naadloze gebruikerservaring bieden. Probeer Logto Vandaag