Een praktisch IdP-evaluatiekader gebaseerd op echte bedrijfsbehoeften. Behandelt protocol-diepte, migratie, multi-tenancy, AI-gereedheid en de criteria die op de meeste checklists ontbreken.
De meeste artikelen waarin identity providers vergeleken worden, zijn geschreven door identity providers zelf. Verrassend, toch? Ze benoemen de functies die hun product heeft, slaan de tekortkomingen over en noemen het een "objectieve gids".
Dit is niet zo'n gids.
We hebben tientallen echte evaluatieverzoeken van ondernemingen bekeken — de daadwerkelijke spreadsheets en RFP-documenten die inkoopteams naar leveranciers sturen. De patronen zijn duidelijk: engineeringteams onderschatten consequent de criteria die het meest van belang zijn en overschatten juist de minst relevante.
Het resultaat? Teams kiezen een IdP na een demo, ontdekken dat migreren een nachtmerrie is na zes maanden, en beginnen opnieuw met evalueren.
Hier is het evaluatiekader waarvan we hadden gewild dat iemand het ons had gegeven voordat we begonnen. Het is gemaakt voor engineeringteams bij B2B SaaS-bedrijven — de teams die producten bouwen, niet de teams die workforce SSO kopen voor hun werknemers.
Als je aan het scannen bent, hier is de korte versie:
De rest van deze gids doorloopt elk evaluatiedomein in detail, met concrete vragen en rode vlaggen om op te letten.
Deze gids is voor jou als:
Deze gids is NIET voor jou als:
Elke IdP op de markt zegt OAuth2 en OIDC te ondersteunen. Dat is vanzelfsprekend. De echte vragen gaan over de diepgang.
Vereist:
Steeds crucialer:
Vraag die veel teams vergeten: Kun je deze IdP als OIDC-provider gebruiken — niet alleen als OIDC-consument?
Waarom het telt: Als je SaaS groeit, willen partners en klanten mogelijk je identity-systeem gebruiken voor login op hun eigen tools. Je moet tokens kunnen uitgeven, consent beheren en registratie van derden regelen. Kan je IdP alleen externe identity providers consumeren en niet zelf als provider fungeren, dan loop je op een gegeven moment vast.
Vraag:
Het token is het contract tussen je IdP en je services. Kun je het niet aanpassen, dan moet elke afnemende service extra API-calls doen om rechten van de gebruiker te achterhalen.
Vraag:
Een token met { "org_id": "org_123", "role": "admin", "auth_level": 2 } betekent dat je API-middleware authorisatie beslist in één regel. Een token met alleen { "sub": "user_456" } betekent dat elke service terug moet naar de IdP of database voor meer info. Op schaal is het verschil 2ms versus 200ms per verzoek.
Elke IdP ondersteunt email/wachtwoord en sociale login. Gefeliciteerd, nu vallen alleen alle IdP’s nog af.
Het verschil zit 'm in de details die in demo's onbesproken blijven.
Hier gaan demo's uiteenlopen. Sessie- en tokenmanagement is saai tot het misgaat — dan wordt je hele gebruikerspopulatie tegelijk uitgelogd.
Niet sexy, wel essentieel.
app.jouwproduct.com en je API op api.jouwproduct.com, kunnen sessies die domeinen overspannen? Hoe?Gebruikers willen weken, geen minuten, ingelogd blijven. Een sessie van 180 dagen heeft totaal andere beveiligingsimplicaties dan 30 minuten.
Vraag:
Role-Based Access Control is de ondergrens. Heeft de IdP geen RBAC, dan hoef je niet verder te kijken. Maar voor B2B SaaS is alleen RBAC niet genoeg.
Je gebruikers horen bij organisaties. Hun rechten binnen iedere organisatie verschillen van hun platformrechten.
Eén gebruiker kan admin zijn in Org A en alleen-lezer in Org B. Dezelfde gebruiker, twee verschillende rollen. Kan de IdP dit niet natively modellen, bouw je dus je eigen permissiesysteem — twee bronnen van waarheid.
Vragen:
Voor financiële, zorgapplicaties, of situaties met risicovolle acties: niet elke sessie is gelijkwaardig.
Dashboard bekijken? Sessie-cookie is genoeg. Overschrijving starten? Verse MFA-verificatie, ook als gebruiker al is ingelogd.
Step-up-authenticatie vereist het concept authenticatieniveau (auth_level) als first-class in tokens.
Vraag:
auth_level claim die je backend kan controleren?auth_level een eigen geldigheid los van de sessie?Als je IdP dit niet standaard heeft, ga je het zelf bouwen — precies het type logic waarvoor je juist een IdP koopt.
Het ideaal: je API leest het token, ziet org, rol en auth_level van gebruiker, en bepaalt autorisatie zonder externe service.
De realiteit bij veel IdPs: het token zegt wie de gebruiker is, maar voor rechten heb je aparte API call(s) nodig.
Extra call betekent latency, afhankelijkheid, faalrisico. Bij 1.000 requests per seconde wil je geen authorizationcheck over het netwerk sturen.
Een statistiek die niemand graag noemt: de meeste IdP-evaluaties stranden niet omdat de nieuwe IdP onvoldoende is, maar omdat het team hun gebruikers niet kan migreren.
Bij 100K+ gebruikers is migratie geen "nice to have" — het is het hele project.
1. Bulk import met bestaande password-hashes
Je gebruikers hebben wachtwoorden gehasht met bcrypt, argon2 of anders. Kan de IdP die hashes importeren en wachtwoorden daarop valideren?
Ja? Gebruikers loggen in met hun huidige wachtwoord, alles blijft gelijk. Beste scenario.
Nee? Iedereen krijgt een "reset je wachtwoord" mail. Je verliest 30-50% van je gebruikers. Dit is niet hypothetisch — het gebeurt.
2. Progressieve (lazy) migratie
Migreer niet iedereen tegelijk, maar bij de eerstvolgende login. Oude systeem checkt het wachtwoord, maakt gebruiker aan in ruime IdP, volgende logins lopen direct via de IdP.
Dit is veiligst bij grote gebruikersaantallen, maar vereist dat de IdP:
3. Dual-write (systemen parallel laten draaien)
Tijdens overgang blijven beide systemen actief. Writes naar allebei, reads verschuiven geleidelijk. Geeft rollback-mogelijkheid, maar maakt het operationeel complexer.
Kan de leverancier deze vragen niet goed beantwoorden, dan geen verdere tijd verspillen.
B2B SaaS is multi-tenancy: je klanten zijn organisaties met meerdere gebruikers, rollen en toegangsregels. De IdP moet hier native weet van hebben.
Sommige IdPs hebben geen native organisatiemodel en raden custom metadata (user.app_metadata.org_id = "123") aan als workaround.
Dit gaat snel mis:
Zegt de leverancier "je kunt orgs modelleren via metadata," dan bewaar je relationele data in een JSON-kolom. Werkt tot het niet meer werkt.
Twaalf maanden geleden stond "AI-agent authenticatie" nergens op een checklist. Vandaag — als je AI in je product bouwt (copilots, autonome agents, AI-gestuurde workflows) — moet je IdP een nieuw identiteitstype aankunnen: de agent.
Traditioneel zijn er twee actoren: gebruiker en applicatie. OAuth2 is hierop gebouwd.
AI agents brengen een derde actor: een niet-menselijk entiteit die namens een gebruiker optreedt, met beperkte rechten en een eigen auditspoor nodig heeft.
Token Exchange (RFC 8693): De agent toont z’n eigen credential plus toestemming van de gebruiker en krijgt een scoped token terug. Het token omvat: wie (de gebruiker), wat (de agent), scope (toestemmingsgrens) en wanneer (vervaldatum).
Agent als client type: De agent moet als volwaardige OAuth2-client met eigen client_id te modelleren zijn, niet gehackt via API keys of usertokens.
Gedelegeerd scope beheer: Gebruiker kan specifieke rechten aan een agent toekennen — lezen, geen schrijven, toegang tot slechts deel van de resources.
Audit-onderscheid: Je logs moeten kunnen tonen: "gebruiker deed X" en "agent deed X namens gebruiker". Anders faal je de komende SOC2 audit op "wie voerde deze actie uit?"
MCP wordt snel dé standaard voor AI-agents die met tools en services praten. Ondersteunt je IdP OAuth-based auth naar MCP servers, dan kunnen agents formeel authenticeren — geen API keys meer.
Heeft de leverancier hier niet aan gedacht, dan bouwen ze voor 2020, niet voor 2026.
Features verkopen. Operaties bepalen of je verlengt.
Na alle dimensies heb je een vergelijkingsmethode nodig. Hier is het prioriteitskader:
| Criterium | Waarom P1 |
|---|---|
| Password hash import of progressieve migratie | Onbruikbaar zonder migratie |
| Authorization Code + PKCE support | Security ondergrens |
| Native organisatiemodel | Eis voor B2B SaaS |
| SOC2 Type II of duidelijke roadmap | Enterprise klant eist het |
| 99,9%+ uptime SLA | Auth down = product down |
| Criterium | Waarom P2 |
|---|---|
| Custom JWT claims | Voorkomt per-request permission lookups |
| Per-org authentication policies | Enterprise onboarding |
| Organisatiescoped rollen & tokens | Multi-tenant autorisatie |
| Refresh token rotatie & intrekbaarheid | Security best practice |
| Hosted UI + custom UI-optie | Flexibel voor verschillende use-cases |
| Criterium | Waarom P3 |
|---|---|
| Token Exchange (RFC 8693) | AI agent authenticatie |
| OIDC Provider mogelijkheid | Partner federatie |
| Step-up authenticatie / auth_level | Financiële of gevoelige handelingen |
| SCIM provisioning | Directory-sync voor enterpriseklanten |
| Passkey / WebAuthn support | Passwordless richting |
| Criterium | Waarom P4 |
|---|---|
| Ingebouwd analytics dashboard | Kan uit audit logs worden gebouwd |
| White-labeled emailtemplates | Gemak |
| Visuele flow builder | Gemak |
| Out-of-the-box social connectors (meer dan de top 5) | Long tail providers |
Hoe toe te passen: Start met P1. Faalt een leverancier op één P1-criterium, stop dan. Scoreer dan P2 en P3. De partij met de beste P2+P3-score is jouw winnaar.
We zien teams steeds dezelfde fouten maken. Zo vermijd je ze:
Featurevergelijkingstabel zegt wat er is, niet hoe het is gebouwd. Een IdP kan organisaties "ondersteunen" door een org_id in metadata, maar dat geeft in productie problemen.
Oplossing: Vraag bij elke feature "hoe is dit geïmplementeerd?" — niet alleen "heb je dit?"
Teams kiezen de "beste" IdP, starten de implementatie, en ontdekken dan dat migreren alleen kan via massale password resets. Nu vast, of opnieuw beginnen.
Oplossing: Maak migratievereiste je eerste filter.
Elke demo is gepolijst. Alleen het ideale pad met gladde data. Jouw productie heeft users met samengevoegde accounts, rare unicode en spooksessies.
Oplossing: Vraag proof-of-concept met echte data van jou. Importeer 1.000 users en test echte flows.
Doet alleen het platformteam de evaluatie, dan kiezen ze technisch schoonste. Alleen product? Dan telt integratiegemak. Alleen security? Dan compliance.
Oplossing: Betrek platform-engineering, product én security. Ieder bewaakt z’n eigen P1/P2.
Vendor lock-in is echt. Proprietary SDK’s/APIs of tokens maken migratie daarna moeilijk.
Oplossing: Kies IdPs die standaarden (OIDC, OAuth2, SCIM) gebruiken. Je toekomstige zelf zal je dankbaar zijn.
Voor een grondige selectie met proof-of-concept: reken op 4-8 weken. Haasten leidt tot de migratiefout hierboven. Reken 2 weken voor eiseninventarisatie, 2-3 weken voor leveranciers-selectie en PoC, en 1-2 weken voor afstemming met stakeholders.
Hangt van je stadium af. Minder dan 10.000 gebruikers en geen enterprise klanten? Dan is een simpele auth-library misschien oké. Maar bij SSO, multi-tenancy, MFA en compliancekosten zijn eigen systemen duurder dan een IdP. We zien teams 2-3 fte besteden aan auth-onderhoud — dat is $300-500K/jaar aan misgelopen waarde.
Customer Identity and Access Management (CIAM) is wat je eindgebruikers van je product gebruiken — aanmelden, login, profielbeheer. Workforce IAM is wat je medewerkers gebruiken voor interne tools (Okta voor Slack, Google Workspace, etc). Dat zijn aparte beslissingen en beoordelingscriteria. Deze gids gaat over CIAM.
Open source IdPs bieden transparantie (je kunt de code bekijken), portabiliteit (zelf hosten als nodig) en community-bijdragen. Proprietaire IdPs bieden vaak fraaiere UIs en managed services. Belangrijkste vraag is niet "open of gesloten", maar "kan ik weg als het moet?" Open source maakt vertrekken makkelijker dankzij publiek bekende datamodellen en API's.
Bouw je nú al AI die toegang heeft tot userdata namens users (copilots, automatisering, AI-assistants), maak het dan P1. Staat AI op 6-12 maanden roadmap, blijft het P3 maar geef het extra gewicht. AI nu niet relevant? Hou het P4 — check over een halfjaar opnieuw.
Meeste IdPs rekenen op Monthly Active Users (MAU). Maar "MAU" betekenissen verschillen: sommige elke login, andere unieke users, weer anderen M2M-tokens apart. Vraag altijd offerte voor jouw scenario: X users, Y orgs, Z M2M-verbindingen, met jouw authvolume. Vergelijk totalen, niet eenheidsprijs.
Het kiezen van een identity provider is een infra-beslissing, geen feature-beslissing. Je kiest een systeem dat elke eerste gebruikersactie, elke permissiecheck en elk auditlogmoment in je product afhandelt.
Het evaluatiekader hierboven raakt wat ertoe doet — niet alleen de marketingclaims. Gebruik het om kandidaten snel te filteren (P1-criteria eerst), diep te testen (P2 en P3 met PoC), en een keuze voor jaren vast te leggen.
De teams die dit goed doen, behandelen identiteit als infrastructuur — niet als een feature om op te leveren en dan te vergeten.