oauth 2.0oidc

Wat is Opaque token?

Een opaque token is een willekeurige, unieke string die betekenisloos is voor de client, maar dient als een referentiesleutel om autorisatiegegevens op te zoeken in de database van de server.

Wat is een opaque token?

Een opaque token is een willekeurige, unieke string die betekenisloos is voor de client, maar dient als een referentiesleutel om autorisatiegegevens op te zoeken in de database van de server.

Opaque tokens worden meestal gegenereerd met behulp van een Cryptografisch veilige pseudorandom nummergenerator om de onvoorspelbaarheid en veiligheid ervan te waarborgen, en het formaat ervan wordt bepaald door de issuer.

Hier is een voorbeeld van een opaque token:

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

Wat is het verschil tussen JWT (JSON Web Token) en een opaque token?

Het belangrijkste verschil ligt in hoe deze tokens omgaan met en valideren van autorisatie-informatie:

Een opaque token is een willekeurige string die zelf geen informatie bevat. De server moet zijn backend-database raadplegen om eventuele autorisatiegegevens op te halen die aan dit token zijn gekoppeld. Dit maakt opaque tokens volledig afhankelijk van de authorization server voor validatie en interpretatie.

JWT is een zelfvoorzienend token dat alle benodigde informatie binnen zichzelf draagt.

Hier is een voorbeeld van een JWT, het is een base64-gecodeerde string:

eyJhbGciOiJIUzI1NiIs.eyJzdWIiOiIxMjM0NTY3O.SflKxwRJSMeKKF2QT4f

En het bevat drie delen gescheiden door punten:

Header - Bevat informatie over het type token en het algoritme dat wordt gebruikt voor ondertekening. Bijvoorbeeld, {"alg": "HS256", "typ": "JWT"}.
Payload - Bevat claims—stukjes informatie over de gebruiker of de autorisatie, zoals gebruikers-ID, vervaltijd en scopes. Iedereen kan het decoderen om de claims te zien omdat het gecodeerd maar niet versleuteld is.
Signature - gegenereerd door de header, payload en een geheime sleutel te combineren met behulp van het gespecificeerde algoritme. Deze handtekening wordt gebruikt om de integriteit van het token te verifiëren en ervoor te zorgen dat het niet is gewijzigd.

Deze structuur stelt JWT’s in staat om te worden gevalideerd en gebruikt zonder een database te raadplegen.

Voor meer gedetailleerde informatie over JWT’s, raadpleeg JSON Web Token (JWT) .

En bekijk Opaque token vs JWT om meer te leren over hun verschillen in meer diepte.

Hoe valideer je een opaque token

In eenvoudige systemen wordt de validatie van een opaque token meestal direct door de server afgehandeld, die de database raadpleegt met behulp van het opaque token als sleutel om de bijbehorende autorisatie-informatie op te halen.

In systemen met meerdere partijen die OAuth 2.0 introduceren, kunnen meerdere resource servers (zie: Resource server ) hetzelfde opaque token moeten valideren. OAuth 2.0 biedt een gestandaardiseerd token introspection mechanisme voor deze validatie:

Voor gedetailleerde informatie over token introspection, raadpleeg Token introspectie (Token introspection) .

Hoe worden opaque tokens gebruikt in OIDC?

In de context van OIDC ( OpenID Connect (OIDC) ) dienen opaque tokens specifieke doeleinden in verschillende scenario’s:

Gebruikersprofiel ophalen

Standaard, wanneer een client een access token aanvraagt zonder een resource te specificeren en de openid scope opneemt, geeft de authorization server een opaque access token uit. Dit token wordt voornamelijk gebruikt om gebruikersprofielinformatie op te halen van het OIDC /oidc/userinfo endpoint (zie: Userinfo-endpoint ).

Refresh token uitwisseling

Refresh tokens (zie: Vernieuwen token (Refresh token) ) worden meestal uitgegeven als opaque tokens omdat ze alleen worden uitgewisseld tussen de client en de authorization server. Wanneer het huidige access token verloopt, kan de client het opaque refresh token gebruiken om een nieuw access token te verkrijgen zonder de gebruiker opnieuw te authenticeren.

Wat zijn de voor- en nadelen van een opaque token?

Voordelen

Veiligheid: Opaque tokens zijn perfect voor het omgaan met gevoelige gegevens zoals refresh tokens. Aangezien de inhoud volledig willekeurig en betekenisloos is, kan zelfs als iemand het token onderschept, hij geen bruikbare informatie extraheren. Dit maakt ze bijzonder waardevol in scenario’s met hoge beveiliging, zoals banktransacties of het omgaan met gevoelige gebruikersgegevens.
Herroepbaarheid: De server kan op elk moment een opaque token onmiddellijk ongeldig maken. Dit is vooral handig wanneer je snel gebruikers toegang moet verwijderen. In tegenstelling tot JWT’s die geldig blijven totdat ze verlopen, kunnen opaque tokens onmiddellijk worden ingetrokken (zie: Beperkingen van JWT ).
Grootte: Opaque tokens zijn meestal veel korter dan JWT’s. Deze kleinere grootte vermindert het netwerkbandbreedtegebruik en de opslagvereisten. Het voordeel wordt vooral merkbaar in systemen die vaak tokens verzenden, zoals mobiele applicaties of IoT-apparaten.
Eenvoud: De implementatie van opaque tokens is eenvoudig. Je genereert een willekeurige string en slaat deze op met de bijbehorende gegevens. Er is geen noodzaak om complexe versleuteling of handtekeningverificatie af te handelen zoals bij JWT’s. Deze eenvoud maakt ze ideaal voor interne systeemauthenticatie.

Nadelen

Stateful: Elk opaque token vereist opslag aan de serverzijde. Dit creëert extra complexiteit in gedistribueerde systemen omdat tokengegevens moeten worden gesynchroniseerd over meerdere servers. Bijvoorbeeld, als je meerdere authentication servers hebt, moeten ze allemaal toegang hebben tot dezelfde token database of cache systeem om tokens correct te valideren.
Prestaties: Tokenvalidatie vereist altijd een database-opzoeking of API-aanroep. In systemen met veel verkeer kunnen deze extra database-opzoekingen prestatieknelpunten creëren. Bijvoorbeeld, als je systeem duizenden verzoeken per seconde verwerkt, elk met tokenvalidatie, wordt de extra databasebelasting aanzienlijk.
Interoperabiliteit: Verschillende systemen kunnen opaque tokens op verschillende manieren implementeren. Dit kan integratie-uitdagingen veroorzaken bij het werken met externe services of verschillende authorization servers. Hoewel standaarden zoals OAuth 2.0 token introspection helpen, kun je nog steeds compatibiliteitsproblemen tegenkomen wanneer systemen verschillende tokenformaten of validatiemethoden gebruiken.