De punten verbinden: Een diepgaande verkenning van OIDC-bron en je JWT-toegangstokens

Achtergrond#

In een vorige sessie hebben we een introductie gegeven tot het OpenID Connect (OIDC) Protocol, vernieuwingstokens, toegangstokens en ID-tokens, essentiële componenten voor het bouwen van robuuste authenticatie in je applicatie. Echter, vragen blijven hangen in onze gemeenschap, met één terugkerende vraag: "Waarom is mijn toegangstoken geen JWT?"

Voor degenen die nieuw zijn met de concepten, of zelfs voor degenen die een opfrissing nodig hebben, is dit blogbericht bedoeld om licht te werpen op de relatie tussen OIDC-bronindicatoren en hun rol bij het verkrijgen van toegangstokens.

Begrip van OIDC-bron#

Als je bekend bent met het OAuth 2.0-protocol, zou de term "bron" een belletje moeten doen rinkelen. Aangezien OIDC is gebouwd op OAuth 2.0, erft het ditzelfde concept.

Een "bron" of "beschermde bron" is een weergave van een entiteit die de clientapplicatie namens de geauthenticeerde gebruiker wil benaderen. Dit kan gebruikersinformatie zijn, server-API's of andere gegevens die door je server zijn geautoriseerd.

Volgens het protocol is de bron een parameter in verzoeken aan de autorisatieserver. Het is een waarde die wordt weergegeven als een absolute URI, zoals https://mijn-bedrijf.com/api. Het fungeert als een identificator voor de bron, die mogelijk overeenkomt met een locatie die kan worden genetreerd over het netwerk of zelfs een unieke maar fictieve URI.

In Logto kun je een “API-bron” maken via de pagina “Beheerdersconsole → API-bronnen”. Je kunt naar deze documentatie verwijzen voor meer details.

JWT-toegangstoken#

Het JWT (JSON web token)-formaat toegangstoken wordt alleen uitgegeven wanneer de "bron"-parameter is gespecificeerd tijdens het aanvragen van het toegangstoken, en het bevat een reeks claims, die je kunt decoderen en valideren, bijvoorbeeld om de integriteit van het token en de permissies van de gebruiker te garanderen.

Deze "bron" wordt dan een van de aud tokenclaims in de JWT, wat de bedoelde doelgroep voor het token aangeeft. Zie RFC-7519.

Dus, de relatie wordt duidelijk:

• Specificeer de bronindicator bij het aanvragen van een JWT-token.
• De bronindicator stemt overeen met de aud tokenclaim.
• Bij het maken van API-verzoeken moet het JWT-toegangstoken worden opgenomen als de draagtoken-header. Je API-server moet de aud-claim en andere permissiegerelateerde claims decoderen en valideren om het API-verzoek te beveiligen.
• Elk toegangstoken komt overeen met een enkele bron. Als je meerdere API-bronnen hebt geregistreerd met verschillende URI's, vraag dan afzonderlijke toegangstokens aan voor elk.

🤔 Maar wat als de client de bron niet specificeert bij het aanvragen van het toegangstoken?

Ondoorzichtig toegangstoken#

In het geval van Logto, als de bronindicator niet is gespecificeerd bij het aanvragen van het toegangstoken, neemt de autorisatieserver aan dat het voor de OIDC /userinfo-endpoint is, en dus wordt er een ondoorzichtig toegangstoken uitgegeven dat later door de client kan worden gebruikt om gebruikersprofielinformatie zoals gebruikers-ID, naam, e-mail, enz. op te vragen bij de OIDC-userinfo-endpoint.

In elke Logto SDK kun je een dergelijk token verkrijgen als je getAccessToken() aanroept of direct een OIDC-tokenendpoint aanvraagt zonder de resource-parameter te specificeren.

Wees bewust dat dit ondoorzichtige toegangstoken niet geschikt is voor je eigen API-bronverzoeken, aangezien er geen manier is om het te verifiëren zonder bij de OIDC-server aan te vragen.

Samenvattend#

OIDC-bronnen definiëren specifieke gegevens of diensten die een clientapplicatie namens de gebruiker wil benaderen, waarbij JWT-toegangstokens dienen als het beveiligde middel voor deze toegang. De "aud"-claim in JWT-toegangstokens stemt overeen met de bronindicator, wat servers helpt bij het verifiëren van permissies bij clientverzoeken.

In Logto is het ondoorzichtige toegangstoken uitsluitend bedoeld voor het ophalen van gebruikersprofielinformatie van de OIDC-userinfo-endpoint, terwijl clients meerdere toegangstokens kunnen aanvragen, elk gewijd aan een specifieke bron.

We hopen dat dit blogbericht eventuele twijfels wegneemt en de punten voor je verbindt. Voel je vrij om ons je gedachten te laten weten.