App Registration en OAuth-gids voor veilige app-integratie

By Mirko Peters · 2026-05-04

Registreer je app met OAuth 2.0. Begrijp de authorization code flow voor veilige toegang, een belangrijk onderdeel van de OAuth 2.0 authorization code grant.

Automatically translated with AI from the original post. Read the English original

Laten we eerlijk zijn: authenticatie en app-registratie goed inrichten gaat niet alleen om slimme protocollen volgen. Het gaat erom dat je gebruikers, je data en je organisatie veilig blijven. Deze gids ontrafelt app-registratie en OAuth 2.0, zodat je veilige, op standaarden gebaseerde authenticatie kunt bouwen met Microsoft Entra ID (voorheen Azure AD) of de provider naar keuze.

We lopen de stappen en concepten door die je nodig hebt, van het begrijpen van het waarom achter OAuth tot het echt aan de slag gaan op web-, mobiele of SaaS-apps. Onderweg vind je heldere definities, praktisch advies en een routekaart die je integratie op koers houdt en de veelvoorkomende fouten vermijdt waar ontwikkelaars die nieuw zijn met OAuth vaak in trappen. Of je nu voor het eerst verkent of een geavanceerde enterprise-opzet fijn afstelt, je bent hier op de juiste plek om met vertrouwen te bouwen en de identifiers te begrijpen die je applicatie nodig heeft.

App Registration & OAuth Guide: definitie

App-registratie is het proces waarbij je een applicatie-identiteit aanmaakt en configureert bij een identity provider (zoals Azure AD, Google of Auth0), zodat de applicatie veilig authenticatie en autorisatie kan aanvragen. Dit omvat meestal het toekennen van een client-ID, een client secret of certificaat, het definiëren van redirect-URI's, het instellen van machtigingen/scopes en het configureren van toegestane grant-types.

8 verrassende feiten over App Registration & OAuth Guide

• Client secrets kunnen via logs lekken: Veel ontwikkelaars loggen tijdens het debuggen per ongeluk client-ID's en secrets. Zonder strengere logginginstellingen zijn de inloggegevens van je app-registratie dan kwetsbaar. Behandel identifiers dus altijd met zorg.
• Redirect-URI's zijn strenger dan je verwacht: OAuth-providers vereisen vaak een exacte overeenkomst van de redirect-URI (inclusief afsluitende slashes en schema). Kleine verschillen kunnen flows laten vastlopen die in je app-registratie correct lijken te zijn ingesteld.
• Public clients hebben geen secrets nodig, maar moeten wel beschermd worden: Native apps en single-page apps worden behandeld als public clients zonder client secrets. Toch moeten ze PKCE gebruiken en veilige redirect-methoden toepassen om onderschepping van de code te voorkomen.
• Scopes garanderen standaard geen least privilege: Bij het registreren van apps kunnen standaardscopes of toestemmingsschermen brede machtigingen vragen. Expliciete scopebeperkingen en incrementele toestemming zijn essentieel om least privilege af te dwingen.
• Tokenintrekking wordt niet overal ondersteund: Niet alle identity providers honoreren tokenintrekking of bieden directe uitloging over alle sessies heen. Daarom moet app-registratie sessiebeheer en beleid voor refresh tokens bevatten.
• Metadata van app-registraties is een aanvalsoppervlak: Openbaar zichtbare app-namen, logo's en redirect-URI's kunnen aanvallers helpen overtuigende phishing- of open redirect-aanvallen op te zetten als ze niet zorgvuldig worden beheerd.
• Geautomatiseerde provisioning kan machtigingen verkeerd instellen: CI/CD-automatisering die app-registraties aanmaakt, kent vaak te ruime API-machtigingen toe of registreert vereiste redirect-URI's niet, wat leidt tot stille fouten of beveiligingsrisico's.
• Het ontwerp van de toestemmingservaring beïnvloedt beveiligingsbeslissingen: Gebruikers en beheerders verlenen vaak brede toestemming omdat toestemmingsdialogen onduidelijk zijn. Duidelijke, minimale toestemmingsvragen in de app-registratie en de OAuth-gids verminderen het te ruim verlenen van toegang.

Inleiding tot OAuth 2.0 en de basisprincipes van Entra ID

OAuth 2.0 is de ruggengraat van moderne authenticatiestromen. Het stelt apps in staat veilig toegang te krijgen tot gegevens en resources van gebruikers, zonder ooit een wachtwoord te zien. Dit is een overzicht van het OAuth-proces. In de kern bepaalt OAuth 2.0 hoe een gebruiker (de ‘resource owner’), een app (de ‘client’) en een identity provider (de ‘authorization server’) samenwerken, zodat gebruikers de controle over hun gegevens behouden.

Maar wat als je gebruikers wilt authenticeren en niet alleen toegang tot gegevens wilt autoriseren? Daar komt OpenID Connect om de hoek kijken. Het voegt veilige identiteit en inloggen toe bovenop OAuth 2.0. Met OpenID Connect kunnen providers zoals Microsoft Entra ID en Google je apps laten controleren wie gebruikers zijn, en kunnen ze in één uniforme ervaring beperkte machtigingen voor aanvullende resources aanvragen.

Als je termen hoort als ‘client ID’, ‘authorization endpoint’ of ‘access token’, laat je dan niet overweldigen. Ze draaien allemaal om de vraag wie met wie communiceert en wat die partij mag doen. Microsoft Entra ID gebruikt deze protocollen met name om ontwikkelaars een op standaarden gebaseerde basis te bieden, van eenvoudige business-apps voor één tenant tot grootschalige multi-tenant SaaS-producten.

Wie deze basisprincipes begrijpt, bouwt op bewezen fundament. Als je de juiste OAuth-flow kiest voor je scenario, bijvoorbeeld de code flow voor webapps of de device flow voor smart-tv’s, zorg je voor een veilige aanmelding waarop gebruikers kunnen vertrouwen en waar je compliance-team blij mee is.

App-registratie en OAuth-gids: veelgemaakte fouten met OAuth 2.0 en Entra ID

Deze gids voor app-registratie en OAuth somt veelvoorkomende fouten op die teams maken bij het implementeren van OAuth 2.0 met Microsoft Entra ID (Azure AD), en beschrijft hoe deze fouten de beveiliging, de functionaliteit en de gebruikerservaring beïnvloeden.

• OAuth 2.0 en OpenID Connect-concepten door elkaar halen, bijvoorbeeld verwachten dat er ID-tokens worden uitgegeven terwijl er alleen access tokens worden verstrekt.
• OAuth-flows verkeerd gebruiken, bijvoorbeeld de impliciete flow gebruiken voor moderne apps in plaats van Authorization Code met PKCE.

• Redirect-URI’s verkeerd registreren, bijvoorbeeld met het verkeerde schema, een afsluitende schuine streep of localhost in productie.
• Instellingen voor public clients gebruiken voor vertrouwelijke apps of andersom, met tokenfouten of blootgestelde geheimen als gevolg.
• De juiste API-machtigingen of scopes niet instellen, of vergeten beheerderstoestemming te verlenen waar dat vereist is.

• Clientgeheimen opnemen in code aan de clientkant of in openbare repositories.
• Geheimen en certificaten niet regelmatig vernieuwen, of verlopen referenties niet verwijderen uit de app-registratie.
• Onnodig langlevende geheimen gebruiken in plaats van kortlevende certificaten of beheerde identiteiten.

• Tokens niet goed valideren (issuer, audience, handtekening, nonce, exp).
• Access- of refresh-tokens onveilig opslaan, bijvoorbeeld in de lokale opslag van de browser zonder bescherming.
• Vertrouwen op de inhoud van tokens zonder de scopes of rollen die Entra ID teruggeeft te controleren.

• Aannemen dat toestemming van de gebruiker gelijkstaat aan app-machtigingen, zonder te beseffen dat sommige machtigingen beheerderstoestemming vereisen.
• Te veel machtigingen of scopes aanvragen, wat leidt tot onnodig risico en meer afwijzingen bij het verlenen van toestemming.

• Refresh-tokenrotatie en intrekkingsbeleid van Entra ID niet afhandelen, waardoor gebruikers onverwacht worden uitgelogd.
• Refresh-tokens gebruiken in public clients zonder goede beveiliging (gebruik PKCE en passende levensduren voor tokens).

• Multi-tenantinstellingen niet goed configureren voor apps die over tenants heen moeten werken.
• De verkeerde endpoints gebruiken (tenantspecifiek of common) en daardoor problemen krijgen met aanmelding of toestemming.

• Niet testen hoe de app zich gedraagt wanneer Voorwaardelijke toegang, MFA of beleid voor apparaatcompliance wordt afgedwongen.
• Ga er niet van uit dat tokens altijd onder dezelfde voorwaarden worden uitgegeven. Beleid kan ze blokkeren of extra verificatiestappen vereisen.

• Verouderde OAuth-flows of Azure AD v1-patronen volgen in plaats van de aanbevelingen van het Microsoft identity platform (v2).
• Community-voorbeelden gebruiken zonder te controleren of ze veilige werkwijzen implementeren (PKCE, veilige opslag, goede validatie).

• Geen logging bijhouden van authenticatiefouten of fouten bij het uitgeven van tokens, waardoor diagnose lastig wordt.
• Ruwe foutmeldingen aan gebruikers tonen in plaats van ze te vertalen naar concrete handelingsadviezen.

Gebruik deze app-registratie- en OAuth-gids om je implementatie te controleren, de best practices van het Microsoft identity platform te volgen en de beveiligings- en operationele risico's te verkleinen bij het integreren van OAuth 2.0 met Entra ID.

Vereisten voor app-registratie bij OAuth-instelling

Voordat je met de registratieschermen aan de slag gaat en de naam van je app in een portal plakt, loop je een paar essentiële punten na. Allereerst heb je toegang nodig tot het Microsoft Entra-beheercentrum van je organisatie, of tot de juiste console van de identity provider die je gebruikt. Hier kun je niet omheen. Zonder de juiste machtigingen loop je al vast voordat je goed en wel binnen bent.

Bepaal vervolgens wat voor soort applicatie je bouwt en welke identificaties nodig zijn voor de werking ervan. Is het een webapp, een single-page-applicatie, een mobiele app of misschien een geautomatiseerde service? Elk type heeft eigen eisen op het gebied van authenticatie en autorisatie. Deze keuze vooraf bepaalt de beveiligingsinstellingen die je later kiest.

Het is ook belangrijk om in kaart te brengen wie je applicatie gaat gebruiken. Gaat het alleen om mensen binnen je eigen organisatie (single-tenant)? Of moet de app gebruikers van andere bedrijven of het grote publiek bedienen (multi-tenant)? Dit bepaalt je registratie-instellingen, welke gebruikersdirectories van toepassing zijn en de toestemmingsstroom die je gebruikers te zien krijgen.

Verzamel ten slotte technische details, zoals toegestane URL's voor sign-in-redirects, welke platforms je ondersteunt (iOS, Android, Windows?) en welke machtigingen (of ‘scopes’) je app nodig heeft. Als deze gegevens vooraf goed op een rij staan, bespaar je veel tijd tijdens de installatie en voorkom je veelvoorkomende problemen, zoals ongeldige URI's of later een verkeerd accounttype.

Zo registreer je je app bij Microsoft Entra ID

Het registreren van je app in Microsoft Entra ID (voorheen Azure AD) legt de basis voor alles wat met authenticatie en API-toegang te maken heeft. Het proces begint in het Entra-beheercentrum, waar je een nieuwe app-registratie aanmaakt. Zo krijgt je app een unieke identiteit (de ‘client-ID’) binnen de directory van je organisatie.

Je geeft je applicatie een naam en kiest daarna wie hem mag gebruiken: alleen je eigen organisatie, meerdere organisaties of elk Microsoft-account. Deze stap is cruciaal, zeker voor SaaS- en B2B-apps, omdat hij bepaalt hoe ver het bereik van je app gaat en hoe tenant-toestemming wordt beheerd.

Nadat je het doelpubliek hebt gekozen, configureer je de platformdetails van je app. Voor webapps voeg je een redirect-URI toe; voor mobiele apps of single-page-apps zorgen platformspecifieke instellingen voor een soepele aanmeldervaring. In het Entra-portaal doorloop je het toevoegen van referenties, zoals clientgeheimen of certificaten, waarmee je app zijn identiteit bewijst.

Met het voltooien van de registratie sluit je app aan op de OAuth 2.0-standaarden en zorg je dat de authenticatiestroom veilig en compliant blijft. Of je nu kiest voor single-tenant of multi-tenant: als je deze instellingen vroeg begrijpt, leg je een stevige basis voor schaalbaarheid en toekomstige integraties.

Belangrijkste voordelen van het registreren van je app bij Microsoft Entra ID

• Gecentraliseerd identiteitsbeheer: beheer authenticatie, autorisatie en gebruikersidentiteiten voor je app vanuit één Entra ID-tenant.
• Veilige OAuth-flows: gebruik de ingebouwde ondersteuning voor OAuth 2.0 en OpenID Connect om veilig aanmelden, het uitgeven van tokens en gedelegeerde toegang te implementeren.
• Single sign-on (SSO): zorg voor naadloze SSO over Microsoft 365, Azure en andere geïntegreerde diensten, zodat de gebruikerservaring verbetert en er minder wachtwoordprompts verschijnen.
• Fijnmazige machtigingsbeheer: definieer en beheer fijnmazige API-machtigingen, toestemmingservaringen en least-privilege-toegang voor zowel gedelegeerde als applicatiemachtigingen.
• Voorwaardelijke toegang en beveiligingsbeleid: dwing MFA, apparaatcompliance, locatie- en risicogebaseerd beleid af om app-toegang en gevoelige gegevens te beschermen.
• Beheerde app-geheimen en referenties: sla clientgeheimen, certificaten en multi-tenantconfiguratie veilig op en roteer ze, met lifecyclemanagement om de integriteit van het gebruik van de apps te waarborgen.
• Integratie met Microsoft-platformdiensten: benader Microsoft Graph, Azure-API's, Teams en andere platformmogelijkheden met gestandaardiseerde tokens en toestemmingsmodellen.
• Ondersteuning voor hybride en multiplatformapps: authenticeer gebruikers op web, mobiel, desktop en voor service-naar-servicescenario's met consistente identiteitsprotocollen, en zorg dat elke app de juiste identifiers gebruikt.
• Monitoring en auditing: gebruik logs, aanmeldingsrapporten en beveiligingsinzichten om afwijkingen te detecteren, incidenten te onderzoeken en compliance te behouden.
• Schaalbaarheid en geschiktheid voor grote organisaties: maak gebruik van de wereldwijde infrastructuur van Entra ID, multi-tenantopties en enterprisefuncties om groeiende gebruikersaantallen en complexe organisatiebehoeften te ondersteunen.
• Ontwikkelaarstools en documentatie: profiteer van SDK's, voorbeeldcode en de gids over app-registratie en oauth om de implementatie te versnellen en veelvoorkomende scenario's op te lossen.

Redirect-URI's en platforminstellingen configureren voor Entra ID-apps

Het instellen van de juiste redirect-URI's tijdens de app-registratie lijkt eenvoudig, maar deze stap is cruciaal voor de beveiliging. Redirect-URI's vertellen Entra ID waar gebruikers (samen met hun tokens) naartoe gestuurd moeten worden na een geslaagde aanmeldingspoging. Bij het instellen past Entra strikte regels toe: geen wildcard-domeinen, geen gevaarlijke URI-schema's en geen losse eindjes die aanvallers kunnen misbruiken.

Als je een single-page application (SPA) bouwt, gebruik je doorgaans een HTTPS-URL die naar het domein van je app verwijst, zodat de communicatie veilig verloopt wanneer de app gegevens ophaalt. Native apps hebben URI-schema's nodig die gekoppeld zijn aan de naam van de app-bundel of het app-pakket. Dat voorkomt dat willekeurige apps tokens kunnen kapen op hetzelfde apparaat. Webapps gebruiken meestal hun eigen callback-eindpunten voor aanmelding; elk daarvan moet expliciet worden vermeld.

Verkeerde configuraties leiden hier tot de klassieke fout "redirect URI mismatch" en, nog erger, geven aanvallers de kans om tokens te onderscheppen. Neem de tijd om in kaart te brengen op welke platforms je app draait, samen met de bijbehorende redirect-URI's. Dat zorgt voor een soepele authenticatie en gemoedsrust.

Vergeet niet je app-registratie bij te werken wanneer je client-URL's wijzigt, platforms toevoegt of omgevingen uitbreidt, zoals test en productie. Deze URI's strak en overzichtelijk houden is stap één om je tokenstroom waterdicht te houden.

OAuth-stromen en essentiële tokenbeheer

OAuth 2.0 is opgebouwd rond een reeks autorisatiestromen voor uiteenlopende scenario's: webaanmeldingen, mobiele aanmeldingen, server-naar-serveraanroepen of apps die draaien zonder aanwezige gebruiker. De meest populaire en veilige daarvan is de autorisatiecodestroom. Die is ontworpen om gevoelige tokens uit browsers en mobiele apps te houden, en stelt beveiliging voorop.

Zodra een gebruiker is geauthenticeerd en toestemming heeft verleend, ontvangt je app een code met een korte geldigheidsduur. Die code moet je bij het tokeneindpunt inruilen voor toegangs- en vernieuwingstokens. Deze tokens geven tijdsgebonden toegang tot gegevens. Wanneer ze verlopen, kan het vernieuwingstoken een nieuw toegangstoken aanvragen, zodat je sessie actief blijft.

Tokenbeheer gaat niet alleen over vervaldatums; het gaat erom tokens op elk moment veilig te houden. Dat betekent veilige communicatie gebruiken (zoals HTTPS), nooit geheimen in client-side code blootstellen en het least-privilegeprincipe toepassen bij het aanvragen van scopes.

Dit gedeelte bereidt je voor op het begrijpen van hoe OAuth de cruciale handshakes tussen gebruikers, apps en platforms afhandelt, en hoe robuust tokenbeheer doorlopende, veilige workflows ondersteunt, zowel voor eindgebruikers als voor geautomatiseerde systemen.

De OAuth-autorisatiecodestroom implementeren

1. De autorisatie starten: je app stuurt de gebruiker door naar het autorisatie-eindpunt van Entra ID, met gegevens zoals je client-ID, de gevraagde scopes en een unieke, willekeurige state-parameter ter bescherming tegen CSRF.
2. Gebruiker verleent toestemming: de gebruiker bekijkt het toestemmingsscherm, waarop duidelijk staat welke machtigingen je app nodig heeft, en keurt de toegang goed.
3. Ontvang de autorisatiecode: Na toestemming stuurt Entra ID de gebruiker terug naar de redirect-URI die je hebt opgegeven, samen met een tijdelijke autorisatiecode en de state-waarde die je oorspronkelijk hebt ingesteld.
4. Wissel de code in voor tokens: Je backend stuurt de code veilig op naar het Entra-tokeneindpunt, samen met je clientgegevens (en de PKCE-codeverifier, als je die gebruikt). Na verificatie krijg je een access token terug, en vaak ook een refresh token.
5. Gebruik tokens om toegang te krijgen tot API's: Je app voegt het access token nu toe aan elke API-aanvraag, zodat wordt aangetoond dat er namens de gebruiker toegang is verleend. Access tokens zijn maar kort geldig, wat de blootstelling beperkt. Met refresh tokens haal je nieuwe access tokens op voor doorlopende sessies.

Als je deze stappen in de juiste volgorde doorloopt, dicht je beveiligingslekken en voorkom je aanvallen zoals het onderscheppen van codes of misbruik van tokens, zeker wanneer je werkt met publieke clients of gevoelige gegevens verwerkt.

Best practices voor het beheren van de verlooptijd van access- en refresh tokens

1. Sla tokens veilig op: Gebruik veilige opslagoplossingen die door het besturingssysteem worden aangeboden, zoals Keychain op iOS, Keystore op Android, of versleutelde secrets managers op de server. Zet tokens nooit hard-coded in app-binaries en laat ze nooit in logs terechtkomen.
2. Houd rekening met de levensduur van tokens: Controleer de vervaldatum (exp-claim) in elk token en vernieuw het token op tijd, voordat het verloopt, zodat er geen mislukte API-aanvragen en slechte gebruikerservaringen ontstaan.
3. Ondersteun tokenrotatie: Gebruik bij elke aanvraag altijd het nieuwste refresh token en verwijder hergebruikte of verouderde tokens snel. Zo beperk je de impact als een token wordt gecompromitteerd.
4. Beperk de machtigingen per token: Vraag alleen de scopes aan die je nodig hebt en geef de voorkeur aan access tokens met een korte levensduur. Dit beperkt de schade enorm als een token ooit lekt of wordt gestolen.

OAuth-implementaties beveiligen in verschillende contexten

OAuth goed inrichten is meer dan alleen de stappen afvinken. Het gaat om beveiliging in lagen die passen bij de architectuur en het gebruik van je app. Of je app in de browser draait, op een telefoon of volledig in de cloud, je hebt authenticatiestrategieën nodig die bij elke context passen.

Technieken zoals PKCE (Proof Key for Code Exchange) beveiligen de codestroom voor publieke clients en voorkomen dat aanvallers codes onderscheppen en omwisselen voor tokens. Voor apps die in beveiligde omgevingen draaien zijn clientsecrets en certificaten daarentegen je beste hulpmiddelen om identiteit te bevestigen en vertrouwen te beheren.

Zorgvuldig omgaan met tokenopslag en scherp letten op privilegeniveaus helpt onbedoeld lekken te voorkomen en beperkt de mogelijke schade als er toch iets misgaat. Door de juiste beveiligingsmiddelen te kiezen, zoals PKCE, secrets, certificaten en goede scoping, verklein je het aanvalsoppervlak aanzienlijk en vergroot je de kans op een soepele, compliant werking.

Hieronder volgen beproefde strategieën die bewezen effectief zijn tegen veelvoorkomende dreigingen en die je OAuth-opzet helpen robuust te beveiligen voor allerlei soorten apps en omgevingen.

Hoe PKCE de OAuth-autorisatie beschermt in publieke clients

PKCE (Proof Key for Code Exchange) is essentieel bij OAuth in mobiele apps en browsergebaseerde apps, dus publieke clients waarin je geen secret kunt opslaan. Wanneer je de autorisatiecodestroom start, genereert je app een willekeurige ‘code verifier’ en een gehashte ‘code challenge’. Deze waarden gaan mee met de gebruiker en de uiteindelijke tokenaanvraag. Zelfs als een aanvaller een autorisatiecode weet te bemachtigen, kan hij die zonder deze geheime verifier niet omwisselen voor een token. Daardoor zijn aanvallen waarbij codes worden onderschept nagenoeg onmogelijk op Microsoft Entra ID en vergelijkbare platforms.

Clientsecrets, certificaten en federated credentials beheren

• Clientsecrets: Worden gebruikt door vertrouwelijke apps, zoals betrouwbare backendservices, om hun identiteit te bewijzen bij het tokeneindpunt. Bewaar secrets in beveiligde kluizen, roteer ze regelmatig en lever ze nooit mee in client-side appcode.
• Certificaten: Gebruik voor een hoger betrouwbaarheidsniveau X.509-certificaten in plaats van gewone secrets om de beveiliging van de identificaties van je applicatie te versterken. Certificaten maken veiligere validatie mogelijk via publieke/private sleutelparen en zijn ideaal voor gereguleerde sectoren of apps met strenge compliance-eisen.
• Federated credentials: Gebruik voor „bring your own identity”-opzetten federated credentials, zoals de federated identity van Microsoft Entra of externe providers. Zo kun je authenticeren zonder secrets zelf te beheren, wat het beheer minder belastend maakt.
• Pipelineafhandeling: Injecteer en roteer in CI/CD-workflows secrets en certificaten waar nodig en zet ze nooit hard-coded in source control. Automatische waarschuwingen voor verlopen voegen nog een laag veerkracht toe.

Tokens beveiligen en blootstelling aan privileges beperken

• Bewaar tokens alleen op beveiligde locaties (besturingssysteemkluizen, versleutelde serveromgevingen), nooit in opslag die gebruikers kunnen benaderen.
• Verstuur tokens altijd via HTTPS of beveiligde kanalen; gewone HTTP maakt tokens kwetsbaar voor onderschepping.
• Vraag per token alleen de minimale machtigingen (‘scopes’) aan. Vraag nooit meer dan je app nodig heeft.
• Controleer regelmatig het gebruik van tokens en de toegekende privileges, zodat ongemerkt oplopende machtigingen worden voorkomen.

Best practices voor OAuth in mobiele en native applicaties

Mobiele en native apps hebben te maken met specifieke uitdagingen: apparaten raken zoek, apps delen opslagruimte en gebruikers verwachten snelle, bijna onzichtbare aanmelding. Daarom maakt het verschil of je OAuth-best practices op iOS, Android en desktop toepast, met ingebouwde SDK’s en beproefde opslagmechanismen.

De juiste SDK (zoals MSAL voor Microsoft Entra ID) neemt veel zwaar werk uit handen: het beheren van tokens, het afhandelen van vernieuwingslogica en de integratie met beveiligde opslag op besturingssysteemniveau. Bij gevoelige tokens kiezen deze SDK’s standaard de veiligste opslaglocatie en houden ze rekening met apparaat- of besturingssysteemspecifieke eigenaardigheden.

Let ook op een naadloze gebruikerservaring: universal links, deep links en systeembrowserstromen helpen gebruikers de aanmelding af te ronden zonder verwarring of phishingrisico. Als dat goed is ingesteld, stuurt je app gebruikers door naar een veilige, vertrouwde systeemweergave en brengt ze na afloop van de aanmelding weer veilig terug in de app: geen pop-ups, geen tokenlekken.

Deze werkwijzen zijn bedoeld om tokens veilig te houden en het vertrouwen van eindgebruikers te vergroten. Dat verhoogt de adoptie en verkleint later de supportproblemen.

Universal links en first-party native authenticatie

Universal links (op iOS) en app-schema’s (op Android) maken gebruikersauthenticatie een stuk veiliger. Door gebruik te maken van door het besturingssysteem geverifieerde links die gekoppeld zijn aan de identiteit van je app, voorkom je dat kwaadwillende apps aanmeldingsredirects onderscheppen en tokens bemachtigen die niet van hen zijn. Native authenticatie maakt gebruik van vertrouwde systeembrowsers, zodat de echte gebruiker zich aanmeldt. Zo worden phishing, tokendiefstal en onbedoelde aanmeldingen via niet-verwante apps buitengesloten. Samen bieden deze onderdelen een naadloze, veilige ervaring die bijna immuun is voor gangbare mobiele OAuth-dreigingen.

Problemen met OAuth-fouten oplossen en geavanceerde scenario’s

OAuth-integraties verlopen zelden meteen perfect. Fouten en vreemde randgevallen horen erbij. Vaak ontstaan problemen door niet-overeenkomende redirect-URI’s, verlopen codes of onjuiste clientgeheimen, waardoor authenticatiestromen vastlopen en de applicatie niet meer werkt. In deze sectie leer je foutresponses ontcijferen, mislukte uitwisselingen natrekken en problemen oplossen voordat ze bij je helpdesk terechtkomen.

Naast de basis vragen sommige scenario’s om gespecialiseerde OAuth-extensies of niet-interactieve stromen, zoals communicatie tussen server en server, aanmelding van IoT-apparaten of de noodzaak voor sterkere protocolgaranties. Serviceaccounts, mutual TLS en device code flows zijn speciaal ontworpen voor deze eisen.

Met richtlijnen voor zowel veelvoorkomende fouten als geavanceerde toepassingen ben je beter in staat om robuuste OAuth-oplossingen te troubleshooten, ontwerpen en beheren, ook als je app-ecosysteem complexer wordt.

Of je nu een hardnekkige fout bij het token-eindpunt opspoort of je app voorbereidt op de realiteit waarin apparaten met beperkte invoer en headless services overal voorkomen: deze inzichten houden je integraties soepel en veilig.

OAuth-foutresponses ontcijferen en mislukte codeuitwisselingen

• Ongeldige redirect-URI: treedt op wanneer de redirect niet overeenkomt met de geregistreerde lijst. Controleer de invoer en hoofdlettergebruik dubbel.
• Verlopen autorisatiecode: gebruikers doen er te lang over of codes worden opnieuw gebruikt. Gebruik codes altijd maar één keer en snel na ontvangst.
• Niet-overeenkomende clientreferenties: het verkeerde geheim of certificaat is opgegeven. Controleer de referenties en roteer ze indien nodig.
• Ongeldige scope of resource: de gevraagde API of scopes zijn niet toegestaan of verkeerd getypt. Controleer de configuratie en de machtigingen van de app.

Serviceaccounts, apparaten met beperkte invoer en OAuth-extensies

• Serviceaccounts (clientcredentials-stroom): laten apps zich authenticeren zonder gebruiker. Ideaal voor automatisering en taken tussen servers.
• Device code flow: bedoeld voor smart-tv’s en IoT. Vraagt gebruikers zich aan te melden op een ander apparaat. Geschikt waar geen browser beschikbaar is.
• Mutual TLS-extensie: gebruikt certificaten voor zowel server als client. Dit verhoogt de beveiliging van gevoelige integraties en zorgt dat de applicatie sterke authenticatiemethoden gebruikt.
• Dynamische clientregistratie: automatiseert het onboarden van apps in grote SaaS- of multi-tenantomgevingen en vereenvoudigt het beheer van credentials op schaal.

App-registratie- en OAuth-gids in Entra ID

Voordelen

• Gecentraliseerd identiteitsbeheer: integreert met Microsoft Entra ID voor consistente identiteit van gebruikers en apps over alle services heen.
• Sterke beveiligingsmaatregelen: ondersteunt OAuth 2.0, OpenID Connect, voorwaardelijke toegang en fijnmazige machtigingen (scopes en rollen).
• Industriestandaard protocollen: maakt gebruik van breed ondersteunde OAuth/OIDC-standaarden, wat interoperabiliteit met tools en bibliotheken van derden vereenvoudigt.
• Gedetailleerde app-configuratie: biedt instelbare redirect-URI's, certificaten en geheimen, API-machtigingen en brandingopties voor apps.
• Fijnmazig toestemmingsmodel: ondersteunt gedelegeerde en applicatiemachtigingen, met stromen voor beheerderstoestemming om apps met te veel rechten te beperken.
• Enterprisefuncties: ondersteunt multi-tenant apps, B2B-samenwerking en integratie met Microsoft 365- en Azure-services.
• Monitoring en auditing: ingebouwde logs, aanmeldingen en audittrails voor app-registraties en OAuth-stromen, wat helpt bij compliance en probleemoplossing.
• Ontwikkeltools en SDK's: uitgebreide SDK's van het Microsoft identity platform, documentatie en quickstart-voorbeelden maken de implementatie eenvoudiger.

Nadelen

• Complexiteit voor nieuwkomers: configuratie- en machtigingsmodellen (redirect-URI's, reply-URL's, implicit versus authorization code flows, scopes) kunnen nieuwe ontwikkelaars in verwarring brengen.
• Steile leercurve voor beveiligingsfuncties: voorwaardelijke toegang, beheerde identiteiten en geavanceerde tokeninstellingen vereisen diepgaande beveiligingskennis om veilig te configureren.
• Risico op wildgroei aan machtigingen: onjuiste toestemming of brede app-machtigingen kunnen leiden tot apps met te veel rechten als ze niet regelmatig worden beoordeeld.
• Nuances bij tokenbeheer: het omgaan met refreshtokens, tokenlevensduur en intrekking van tokens verschilt per platform, wat tot integratieproblemen kan leiden.
• Overwegingen rond tenantgrenzen: het gedrag van multi-tenant apps en prompts voor beheerderstoestemming maken het beheer ingewikkelder in scenario's over meerdere tenants heen.
• Wijzigingen in UI en terminologie: Microsoft past de Entra-interface en de naamgeving regelmatig aan (Azure AD → Entra ID), wat kan leiden tot verschil tussen documentatie en praktijk of tot verwarring.
• Afhankelijkheid van het Microsoft-ecosysteem: de sterke koppeling met functies van Entra ID kan de overdraagbaarheid naar identity providers buiten Microsoft beperken zonder herwerk.
• Kans op verkeerde configuratie: onjuiste instellingen voor app-registratie (bijvoorbeeld redirect-URI's, reply-URL's, instellingen voor implicit flow) kunnen beveiligingslekken veroorzaken of authenticatiestromen laten vastlopen.

Volgende stappen en belangrijkste communitybronnen voor succes met OAuth

Oké, OAuth staat ingesteld en werkt, maar gas terugnemen mag nog niet; zorg dat de applicatie die tokens ophaalt goed is geconfigureerd. De basis aansluiten is pas stap één. Als je je app echt wilt laten opvallen en je gebruikers veilig wilt houden, is het nu tijd om in de extra's te duiken. Bekijk geavanceerde clientbibliotheken, experimenteer met Microsoft Graph en verken nieuwe identiteitsfuncties die je integratie sterker en soepeler maken voor iedereen die erbij betrokken is.

Je hoeft dit ook niet alleen uit te zoeken. De documentatie van Microsoft Entra ID is zo diepgaand als Lake Michigan: vol actuele handleidingen, codevoorbeelden en alle technische specificaties die je waarschijnlijk bij de hand wilt houden. Maak er een gewoonte van om te controleren op updates, zeker nu OAuth- en cloudidentiteitsstandaarden voortdurend veranderen.

Tevreden met je app-registratie? Mooi. Kijk nu eens hoe anderen in de praktijk creatief te werk gaan. Duik in ontwikkelaarsforums, officiële discussieborden en kijk zelfs even in de GitHub-repository's van authenticatiebibliotheken. Als je vastloopt, heeft iemand anders jouw precieze probleem waarschijnlijk al opgelost, of er in ieder geval luid over geklaagd tot iemand antwoord gaf.

Als je graag knutselt en leert door te doen, bekijk dan beschikbare gratis proefabonnementen, testtenants en publieke previewfuncties. Daarmee kun je veilig dingen kapotmaken en ontdekken wat werkt voordat je wijzigingen uitrolt naar je echte gebruikers. En vergeet niet: OAuth en beveiliging zijn een gezamenlijke inspanning van de community, dus deel je successen en vragen. Zo blijft het hele ecosysteem eerlijk en groeit het sterk, en begrijpt iedereen beter hoe de OAuth-stroom werkt.

Checklist App-registratie- en OAuth-gids - Entra ID

• Bepaal het applicatietype en toegangsmodel: kies tussen single-tenant, multi-tenant of persoonlijke Microsoft-accounts en bepaal of het SPA, webapp, mobiele app, daemon of serviceapp wordt.
• Registreer de applicatie in Entra ID — maak een nieuwe app-registratie aan met een duidelijke naam en de ondersteunde accounttypen.
• Configureer redirect-URI's — voeg de juiste redirect- en callback-URI's toe voor elk platform (https, aangepast schema, localhost voor ontwikkeling).
• Stel de instellingen voor het applicatieplatform in — schakel de platformopties voor SPA, web, mobiel en desktop in en configureer impliciete of grant-flows waar nodig.
• Maak en beheer clientsecrets — genereer clientsecrets voor confidential clients, noteer de vervaldatum en bewaar ze veilig (Key Vault).
• Gebruik certificaten voor authenticatie — upload publieke-sleutelcertificaten voor productie-confidential clients in plaats van langlopende secrets.
• Configureer API-machtigingen — voeg Microsoft Graph- of aangepaste API-scopes en machtigingen toe die de app nodig heeft.
• Verleen beheerderstoestemming waar vereist — vraag beheerderstoestemming aan en leg die vast voor gedelegeerde machtigingen die toestemming voor de hele tenant vereisen.
• Definieer en stel aangepaste scopes beschikbaar (bij een API) — voeg scopes toe onder “Expose an API” en definieer scopenamen, beschrijvingen en weergavenamen voor beheerderstoestemming.
• Stel app-rollen in (indien nodig) — definieer toepassings- en gedelegeerde rollen voor rolgebaseerd toegangsbeheer en wijs ze toe aan gebruikers, groepen of clienttoepassingen.
• Configureer CORS voor SPA's die API's aanroepen — voeg toegestane oorsprongen toe op de API of configureer het gateway- of CORS-beleid.
• Kies de OAuth 2.0-flow — selecteer, afhankelijk van het geval, Authorization Code (met PKCE voor public clients), Client Credentials voor daemon-apps of Device Code.
• Implementeer PKCE voor public clients — vereis Proof Key for Code Exchange voor SPA's en native apps om het onderscheppen van codes te voorkomen.
• Valideer tokens correct — controleer issuer, audience, handtekening, vervaldatum en vereiste claims met Microsoft-identiteitsbibliotheken of JWT-validatielogica.
• Gebruik de Microsoft Authentication Libraries (MSAL) — geef de voorkeur aan MSAL voor het verkrijgen, cachen en vernieuwen van tokens en de veilige verwerking op alle platforms.
• Configureer voorwaardelijke toegang en MFA (indien vereist) — pas beleid toe op de app-registratie of op de aanmeldstromen van gebruikers om beveiligingsmaatregelen af te dwingen.
• Monitor aanmeldingen en auditlogboeken — schakel logging in en controleer aanmeldgebeurtenissen, toestemmingen en beheerdersacties in de Entra ID-logboeken.
• Pas het principe van minimale rechten toe — vraag alleen de machtigingen aan die nodig zijn en geef de voorkeur aan incrementele toestemming om de blootstelling te beperken.
• Roteer secrets en certificaten regelmatig — implementeer geautomatiseerde rotatie en waarschuwingen voor verlopende credentials.
• Beveilig code en opslag aan de clientzijde — sla geen secrets op in clientapps, gebruik veilige opslag en volg de best practices per platform.
• Test aanmeldingen en tokenflows in ontwikkel- en stagingomgevingen — valideer authenticatieflows, levensduur van tokens, vernieuwingslogica, foutafhandeling en de toestemmingservaring.
• Bereid documentatie voor gebruikers en beheerders voor — neem toestemmingsstappen, vereiste machtigingen en probleemoplossingsadvies op.
• Controleer en actualiseer app-registraties periodiek — controleer machtigingen, rollen, secrets en registraties op verouderde of ongebruikte apps.
• Pas netwerk- en API-beveiliging toe — overweeg API Management, WAF, rate limiting en service endpoints om backend-API's te beschermen.

azure access token gebruiken oauth auth

Wat is een app-registratie- en oauth-gids en waarom is die belangrijk?

Een app-registratie- en oauth-gids legt uit hoe je een clienttoepassing registreert bij een identity provider (bijvoorbeeld met Azure) en hoe je OAuth 2.0-autorisatieflows implementeert, zodat je applicatie veilig toegang kan aanvragen tot beschermde resources. Dit is cruciaal, of je nu webapplicaties, single-page apps, desktopapps of webserver-backends bouwt, omdat de applicatie een app-id of application-id en client-id en clientsecret (voor confidential clients) nodig heeft om een access token te verkrijgen en, waar gepast, een id token te ontvangen.

Hoe registreer ik een Azure-app en verkrijg ik de application-id en app-id?

Om een Azure-app te registreren, ga je naar de Azure-portal, maak je een nieuwe app-registratie aan, geef je een naam en redirect-URI's op en noteer je de client-id (application-id) die je in het overzicht van de applicatie ziet. Als je applicatie een confidential client is (webserver of traditionele webapp), maak je een clientsecret aan om samen met de client-id en het clientsecret te gebruiken. Deze geregistreerde applicatie wordt gebruikt bij autorisatie en om access tokens op te vragen bij Microsoft-diensten.

Welke OAuth 2.0-autorisatieflow moet ik gebruiken voor single-page apps?

Single-page apps moeten de autorisatiecodestroom met PKCE (proof key for code exchange) gebruiken in plaats van de impliciete flow. Zo is het ophalen van tokens door de applicatie veilig. Met de codestroom met PKCE kan de applicatie de code veilig uitwisselen voor een access token vanuit een browsergebaseerde client. Single-page apps kunnen zo OAuth gebruiken zonder clientsecrets in de browser bloot te stellen.

Hoe werkt de autorisatieaanvraag en welke parameters zijn verplicht?

Een autorisatieaanvraag wordt verzonden naar het autorisatie-eindpunt van de identity provider en bevat meestal de client_id (app-id), response_type (bijvoorbeeld code), redirect_uri, scope en state. Voor single-page apps die de codestroom met PKCE gebruiken, voeg je ook de code_challenge en code_challenge_method toe. De gebruiker authenticeert zich en geeft toestemming (OAuth-toestemming). De autorisatieserver stuurt vervolgens een code terug naar de redirect URI, en die code kan de applicatie omruilen voor een access token.

Hoe programmeer ik de uitwisseling van een code voor een access token?

Nadat de client-applicatie de autorisatiecode heeft ontvangen, stuurt ze een aanvraag naar het token-eindpunt. Die aanvraag bevat de code, client_id (en client_secret voor confidentiële clients), redirect_uri en grant_type=authorization_code. Bij PKCE voeg je de code_verifier toe. Het token-eindpunt antwoordt met een access token, een id token (indien gevraagd) en mogelijk een refresh token waarmee je een nieuw access token kunt verkrijgen wanneer het huidige verloopt.

Hoe verkrijg ik een access token en gebruik ik dat om API's aan te roepen?

Verkrijg een access token door de gekozen OAuth 2.0-autorisatieflow te doorlopen en het token-eindpunt aan te roepen. Zodra je het access token hebt, stuur je het mee in de Authorization-header als Bearer wanneer je Microsoft-diensten of andere API's aanroept, bijvoorbeeld Google Calendar of eigen API's. Controleer tokens aan de webserver- of resourcekant, zodat duidelijk is dat de aanvragen van de applicatie geautoriseerd zijn.

Wat doe ik wanneer het access token verloopt, en hoe verkrijg ik een nieuw refresh token?

Wanneer het access token verloopt, gebruik je het refresh token (indien beschikbaar) om via grant_type=refresh_token een nieuw access token op te vragen bij het token-eindpunt. Sommige flows of providers geven bij het verversen een nieuw refresh token uit, andere hergebruiken hetzelfde refresh token. Is er geen refresh token beschikbaar (publieke clients of kortlopende flows), stuur de gebruiker dan terug naar je app om een nieuwe autorisatieaanvraag uit te voeren.

Heb ik afzonderlijke app-registraties nodig voor webapplicaties en voor mobiele of desktop-apps?

Vaak heb je afzonderlijke app-registraties nodig wanneer de applicatietypes sterk verschillen, bijvoorbeeld een traditionele webserver, single-page apps en desktop-apps. Redirect-URI's, clientsecrets en toegestane flows verschillen namelijk per type. Met afzonderlijke app-registraties kun je per type applicatie de juiste autorisatieflows en redirect-URI's instellen.

Wat is het verschil tussen een client-app-registratie en een applicatie in een tenant?

Een client-app-registratie is de specifieke registratie-invoer in de identity provider (de Azure-app) die configuratie bevat, zoals redirect-URI's en geheimen. Een applicatie in een tenant geeft aan dat de registratie binnen een bepaalde Azure AD-tenant bestaat en binnen die tenant rollen en machtigingen kan krijgen. Een enkele app-registratie kan multi-tenant of single-tenant zijn, afhankelijk van je behoefte.

Hoe vraag ik toegang tot Microsoft-diensten aan, en welke machtigingen zijn nodig?

Vraag toegang aan door in de autorisatieaanvraag de scopes op te geven die je applicatie nodig heeft. Voor Microsoft-diensten configureer je API-machtigingen in de Azure-app-registratie. Vervolgens vraag je gebruikers om toestemming (OAuth-toestemming) of laat je een beheerder tenantbrede toestemming verlenen. De applicatie vraagt scopes zoals User.Read of eigen API-scopes aan binnen de applicatieaanvragen, en gebruikt het access token om de diensten aan te roepen.

Hoe beveilig ik clientsecrets en voorkom ik dat inloggegevens uitlekken in single-page apps?

Single-page apps mogen geen clientsecrets opslaan, omdat code die in de browser draait kan worden ingezien. Gebruik de codestroom met PKCE, zodat de applicatie veilig een access token kan verkrijgen zonder clientsecret. Bewaar voor confidentiële apps (webserver) de client-id en het clientsecret aan de serverkant, waar gebruikers er niet bij kunnen.

Wat is de rol van de redirect-URI, en waarom moet die overeenkomen met de app-registratie?

De redirect-URI is de plek waar de identity provider het autorisatieantwoord (code of token) naartoe stuurt. Deze moet exact overeenkomen met de redirect-URI die is geregistreerd in de app-registratie, om autorisatieantwoord-hijacking te voorkomen. Gebruik exacte overeenkomst of de toegestane patronen zoals de provider die definieert; een afwijking zorgt ervoor dat de tokenuitwisseling mislukt.

Hoe zorg ik dat gebruikers zich authenticeren en naast een access token ook een id token ontvangen?

Om een id token te ontvangen, vraag je de openid-scope aan en neem je een response_type op die de uitgifte van een id token activeert (autorisatiecodeflow met openid). Het id token bevat identiteitsclaims over de geauthenticeerde gebruiker. Gebruik het id token om de gebruiker in je clienttoepassing aan te melden en het access token om downstream-API's aan te roepen.

Welke specifieke autorisatieflows gelden voor traditionele webapps en voor single page apps?

Traditionele webapplicaties (server-side) gebruiken meestal de autorisatiecodeflow met clientreferenties (client-id en clientgeheim), waarbij de code op de webserver wordt uitgewisseld. Single page apps gebruiken de autorisatiecode-grant met PKCE en zonder clientgeheim. Desktopapps gebruiken ook PKCE. Kies de flow op basis van het type applicatie en de plek waar geheimen veilig kunnen worden opgeslagen.

Kan één app-registratie worden gebruikt voor meerdere clienttoepassingen, of moet ik per app een aparte app-registratie maken?

Je kunt één app-registratie gebruiken voor meerdere clienttoepassingen als ze dezelfde configuratie en redirect-URI's delen. Best practices adviseren echter vaak aparte app-registraties voor afzonderlijke applicaties, zodat machtigingen, redirect-URI's en levenscyclusbeheer goed geïsoleerd blijven. Overweeg of de applicatie andere scopes of andere toestemmingsgedragingen nodig heeft.

Hoe valideer ik tokens in mijn webserver of API?

Je webserver of API moet de handtekening, issuer, audience (app-id of application-id) en vervaldatum van het access token of id token valideren. Gebruik het discovery-document van de provider om de ondertekeningssleutels op te halen en volg de aanbevolen validatiebibliotheken voor je platform. Validatie zorgt ervoor dat alleen verzoeken van geauthenticeerde en geautoriseerde applicaties worden geaccepteerd.

Wat is het proces om een access token voor een backendservice aan te vragen met clientreferenties?

Voor server-naar-server-scenario's registreer je een Azure-app, ken je er applicatiemachtigingen aan toe en gebruik je vervolgens de clientreferentieflow: stuur een POST naar het tokeneindpunt met grant_type=client_credentials, client_id, client_secret en scope/resource. Het tokeneindpunt geeft een access token terug dat de backend kan gebruiken om Microsoft-services of beschermde API's aan te roepen.

Hoe ga ik om met OAuth-toestemming en beheerderstoestemming voor multi-tenant-applicaties?

Wanneer je app als multi-tenant is geregistreerd, kunnen gebruikers uit andere tenants tijdens de autorisatieaanvraag toestemming geven voor gedelegeerde machtigingen. Voor machtigingen die beheerderstoestemming vereisen, moet een beheerder die toestemming verlenen voor de eigen tenant. Voeg instructies en een toestemmings-URL toe voor tenantbeheerders, zodat zij OAuth-toestemming op schaal kunnen verlenen.

Welke stappen voor probleemoplossing kan ik nemen als mijn autorisatieaanvraag mislukt?

Controleer of de app is geregistreerd in het Microsoft-portaal, of de redirect-URI overeenkomt, of de client-id en het geheim correct zijn, of de scopes geldig zijn en of het grant type en de PKCE-parameters (indien gebruikt) juist zijn. Controleer de foutmeldingen die het autorisatie- of tokeneindpunt teruggeeft en raadpleeg de logs aan zowel client- als serverzijde. Stack Overflow en de documentatie van de provider kunnen helpen bij specifieke foutcodes.

Hoe integreer ik API's van derden, zoals Google Agenda, met mijn geregistreerde app?

Om Google Agenda of andere API's van derden te integreren, implementeer je de OAuth 2.0-autorisatieflows die die providers vereisen. Je applicatie moet de juiste scopes voor de API van derden aanvragen en de afzonderlijke levenscycli van tokens afhandelen. Mogelijk heb je per provider aparte clientapplicatie-registraties nodig en moet je het verkrijgen van access tokens voor elke dienst coördineren.

Wanneer moet ik de device code flow of andere speciale flows voor bepaalde apparaten gebruiken?

Gebruik de device code flow voor apparaten met beperkte invoermogelijkheden waar geen browser beschikbaar is. Met de device flow kan een gebruiker op een ander apparaat een verificatie-URL bezoeken om zich te authenticeren. Het is een van de specifieke autorisatieflows die naast de code grant, clientreferenties en refresh token flows worden ondersteund om verschillende typen applicaties te ondersteunen.