Access Token verkrijgen onder de knie: Client Credentials Flow

Dit blogbericht maakt deel uit van een reeks. In dit bericht belichten we de client credentials flow. Bekijk de andere berichten over de andere autorisatiestromen:

• Access Token verkrijgen onder de knie: De authorization code flow
• Access Token verkrijgen onder de knie: Een refresh token gebruiken
• Access Token verkrijgen onder de knie: Een certificaat gebruiken

Een andere belangrijke authenticatiestroom binnen het domein van OAuth 2.0 is de client credentials flow. In tegenstelling tot de authorization code flow werkt de client credentials flow zonder dat enige gebruikersinteractie vereist is.

Bij de client credentials flow is het proces voor het verkrijgen van een access token opmerkelijk gestroomlijnd. Met slechts één POST-verzoek naar het aangewezen token-endpoint en de opname van de client-ID en het client-secret van je applicatie, kun je het access token verkrijgen. Deze efficiëntie is met name voordelig in scenario’s waarbij de applicatie namens zichzelf communiceert met API’s of services, in plaats van een gebruiker te vertegenwoordigen.

Een van de kernvoordelen van de client credentials flow is de eenvoud. De minimale vereisten van een client-ID en client-secret dragen bij aan een versneld autorisatieproces, wat bijzonder waardevol is wanneer snelle tokenverkrijging essentieel is voor het behoud van de applicatiefunctionaliteit.

Het is echter belangrijk op te merken dat deze efficiëntie gepaard gaat met afwegingen. Een belangrijk onderscheid van de client credentials flow is dat het geen refresh token oplevert. Refresh tokens, zoals verkregen via andere stromen, zorgen voor verlengde sessies zonder de noodzaak van herhaalde gebruikersauthenticatie. Bij de client credentials flow betekent de afwezigheid van refresh tokens dat wanneer het access token verloopt, de applicatie opnieuw moet authenticeren en een nieuw access token moet verkrijgen met behulp van de client credentials (client-ID en client-secret).

Je kunt een POST-verzoek doen naar https://login.microsoft.com/[YOUR_TENANT_ID]/oauth2/v2.0/token met de volgende parameters in de body van het verzoek:

• client_id: de id van je client. Deze is te vinden op het startscherm van je app-registratie.
• client_secret: Het client secret van je client-id. Dit is iets wat je kunt genereren in de sectie Certificates & secrets van je app-registratie in Azure.
• grant_type: client_credentials
• scope: het bereik moet de resource-identifier zijn van de applicatie waartegen je je access token wilt gebruiken, aangevuld met .default. Voor Microsoft Graph zou dit bijvoorbeeld https://graph.microsoft.com/.default zijn.

Als alles goed gaat, krijg je een json terug met daarin je access token:

Zoals een lezer als geldig punt opmerkte in een eerder blogbericht, moet beveiliging altijd in acht worden genomen bij het gebruik van dit soort autorisatiestromen.

Client secrets zijn van cruciaal belang in OAuth 2.0 voor clientauthenticatie, maar hun beveiliging verschilt tussen server-side en client-side contexten.

Bij server-side gebruik zijn client secrets beter beschermd omdat ze veilig kunnen worden opgeslagen, bijvoorbeeld in een configuratiebestand of met Azure Key Vault. In de client-side situatie verhoogt het blootstellen van secrets in code echter de kwetsbaarheid. Om de beveiliging te verbeteren, wordt aanbevolen de blootstelling aan de client-side te beperken, waar mogelijk op token gebaseerde stromen te gebruiken of te kiezen voor server-side afhandeling van gevoelige bewerkingen.