Inzicht in toegangstokens, ververstokens en ID-tokens in het OpenID Connect (OIDC) protocol

OIDC, OAuth 2.0 en tokens#

Het OpenID Connect Protocol, ook wel bekend als OIDC, is uitgegroeid tot een breed geaccepteerde standaard die een fundamenteel kader biedt voor identiteitsbeheer. Het is een authenticatielaag gebouwd bovenop het welbekende OAuth 2.0-protocol. Terwijl OAuth 2.0 enkel bedoeld is voor autorisatie van resources, is OIDC het protocol dat cliëntauthenticatie standaardiseert en versterkt, met behulp van het nieuwe geïntroduceerde ID-token.

Wacht... Je hebt wellicht gehoord van toegangstokens en ververstokens in het OAuth-tijdperk, en nu komt hier het nieuwe concept in OIDC? Begrijp je echt de verschillen tussen deze tokens?

Wat zijn de toegangstokens, ververstokens en ID-tokens in OIDC?#

Laten we beginnen met een praktisch scenario.

Stel je voor dat je een typische client-server applicatie ontwikkelt, en ze communiceren met elkaar via RESTful API's. Je wilt het merendeel van je API's privé houden, waarbij alleen geautoriseerde clients toegang hebben. Je hebt een mechanisme nodig om de client te authenticeren en de API-verzoeken aan je server te autoriseren.

Idealiter zouden jouw RESTful API's stateless moeten zijn, wat betekent dat de server geen sessie-informatie van clients zou moeten opslaan. Telkens wanneer een geldig verzoek binnenkomt, zou de server eenvoudig moeten reageren met de gevraagde data. Dat is waar tokens in het spel komen. Dus, welk type token moet je in dit geval gebruiken?

Toegangstokens worden gebruikt om jouw API's te beschermen#

In OAuth 2.0 en OIDC wordt elke beschermde API behandeld als een resource. Het toegangstoken is precies dat token dat de client naar de server verstuurt wanneer hij een API-resource opvraagt, doorgaans via de aanvraagheader en in JWT-formaat.

Aan de serverzijde, telkens als er een verzoek binnenkomt, hoeft de server alleen maar te valideren of het binnenkomende verzoek een geldig toegangstoken bevat. Het validatieproces omvat meestal het decoderen van het JWT-token, het verifiëren van de handtekening en de vervaltijd, evenals de scope-claim om te zorgen dat de client de nodige permissies heeft.

Je zou je echter kunnen afvragen: Als mijn client-applicatie een geldig toegangstoken kan hebben na succesvol inloggen en het toegangstoken gebruiken om server-API's op te vragen, is dat dan niet voldoende? Waarom heb ik de andere tokens nodig?

Inderdaad, een geldige vraag, en laten we het stap voor stap uitleggen.

Waarom hebben we ververstokens nodig?#

Hoewel toegangstokens technisch gezien aan de minimale vereisten voldoen om het systeem te laten werken, zijn vanwege veiligheidsredenen de geldigheid van toegangstokens meestal zeer kort (doorgaans een uur). Dus stel je eens voor als we alleen toegangstokens zouden hebben, zouden de eindgebruikers zich elke keer moeten herauthenticeren wanneer het toegangstoken verloopt. Voor moderne single-page webapplicaties (SPAs) en vooral mobiele applicaties is het frequent uitloggen een vrij pijnlijke gebruikerservaring, ook al proberen we alleen maar hun gebruikersbeveiliging te beschermen.

Daarom hebben we een balans nodig tussen tokensbeveiliging en gebruikersgemak. Daarom zijn ververstokens geïntroduceerd.

Waarom kunnen ververstokens een langere levensduur hebben?#

Toegangstokens worden gebruikt om API-resources te benaderen, dus hun kortlevende aard helpt bij het verminderen van het risico om gelekt of gecompromitteerd te worden. Aan de andere kant, aangezien ververstokens alleen worden gebruikt om nieuwe toegangstokens aan te vragen, worden ze niet zo vaak gebruikt als toegangstokens en is het risico van blootstelling daardoor verminderd. Daarom wordt het acceptabel geacht dat ververstokens een langere geldigheidsperiode hebben.

Waarborgen van de beveiliging van ververstokens#

Aangezien ververstokens ook aan de clientzijde worden opgeslagen, is het waarborgen van hun oncompromitteren uitdagend, vooral voor publieke clients zoals single-page webapplicaties (SPA) en mobiele apps.

In Logto hebben ververstokens een automatische rotatiemechanisme dat standaard is ingeschakeld, wat betekent dat de autorisatieserver een nieuw ververstoken zal uitgeven zodra het aan de criteria voldoet:

• Single-page applicaties: Herkend als niet-afzender gebonden clients, vereist deze apps tokenrotatie. De levensduur van het ververstoken kan niet worden gespecificeerd.
• Native apps en traditionele webapps: Vervestokenrotatie is inherent ingeschakeld, automatisch vernieuwend bij het bereiken van 70% van zijn levensduur. Meer leren

Hoewel je nog steeds de optie hebt om de rotatie van ververstokens uit te schakelen op de applicatie details pagina in de admin console, wordt sterk aanbevolen om deze beveiligingsmaatregel te behouden.

Wat is een ID-token en waarom is het belangrijk?#

Het ID-token is een uniek kenmerk van OIDC dat identiteitsinformatie over de geauthenticeerde gebruiker biedt.

Terwijl toegangstokens worden gebruikt om beschermde resources te benaderen en ververstokens worden gebruikt om nieuwe toegangstokens te verkrijgen, worden de ID-tokens doorgaans gebruikt om gebruikersinformatie op de client side te cachen, waardoor het nodig aantal verzoeken aan de autorisatieserver voor gebruikersgegevens vermindert. In de meeste gevallen is het zelfs veilig om te zeggen dat het hebben van het ID-token gelijk staat aan dat de gebruiker geauthenticeerd is.

Best practices voor het omgaan met tokens#

• Gebruik HTTPS: Gebruik altijd HTTPS om de communicatie tussen de client en de autorisatieserver te beveiligen. Dit voorkomt dat ongeautoriseerde partijen tokens onderscheppen en stelen.
• Stel een geschikte tokenverlooptijd in: Toegangstokens moeten een korte levensduur hebben om het risico van blootstelling te minimaliseren. Vervestokens kunnen een langere geldigheidsperiode hebben.
• Schakel tokenrotatie in: Implementeer rotatie om het risico van lekkage van ververstokens te verminderen.
• Gebruik fijnmazige toegangscontrole: Gebruik fijnmazige scopes om de permissies van toegangstokens te beperken. Vraag alleen de noodzakelijk vereiste permissies voor de client applicatie aan. Vermijd het gebruik van "all" of "admin" scopes om de meeste permissie controles te omzeilen, tenzij absoluut noodzakelijk.

Samenvatting: Belangrijkste verschillen tussen toegangstokens, ververstokens, en ID-tokens in OIDC#

In het OIDC-protocol werken ververstokens, toegangstokens en ID-tokens samen om veilige en naadloze gebruikersauthenticatie te bieden.

• Toegangstokens bieden autorisatie om beschermde resources te benaderen.
• Vervestokens elimineren gebruikersinterventie voor nieuwe toegangstokens.
• ID-tokens bieden gecachte gebruikersinformatie op de client, wat de prestaties verbetert.

Begrijpen van de rol en het belang van deze tokens is cruciaal voor ontwikkelaars die OIDC-authenticatie in hun applicaties implementeren.