Waarom je product OAuth 2.0 en OIDC nodig heeft - Vooral in het AI tijdperk

Vanaf het allereerste begin is Logto gebouwd met een sterk geloof in open standaarden. We hebben ervoor gekozen om protocollen als OIDC, OAuth 2.0 en SAML te volgen — niet alleen omdat ze veel worden gebruikt, maar omdat ze goed gevestigde, veilige praktijken vertegenwoordigen die door de industrie worden vertrouwd. Veiligheid is altijd een prioriteit voor ons geweest. Hetzelfde geldt voor het trouw blijven aan de geest van open source en het naleven van beste praktijken in Customer Identity Management en moderne authenticatie.

Maar we hebben onderweg ook iets geleerd:

OAuth 2.0 en OIDC zijn niet voor iedereen gemakkelijk. Voor ontwikkelaars die nieuw zijn met deze protocollen, kunnen de concepten vreemd en soms zelfs contra-intuïtief aanvoelen. Dit leidde tot echte uitdagingen terwijl we werkten aan het vereenvoudigen van de ontwikkelaarservaring zonder concessies te doen aan de veiligheid.

Twee dingen vielen op:

1. Hoewel we hard hebben gewerkt om integratie zo soepel mogelijk te maken, is er nog steeds een leercurve voor het begrijpen van basisconcepten zoals ID-tokens, toegangstokens en hoe ze werken.
2. Een veelgestelde vraag die we krijgen is: “Kan ik de omleiding op het inlogscherm overslaan?” Helaas is omleiding een kernonderdeel van hoe OIDC werkt en is het noodzakelijk voor veilige authenticatie.

Een veelgestelde vraag van onze Discord-gebruikers (met hun ID en avatar vervaagd voor privacy).

Elke beslissing komt met afwegingen — maar soms blijkt een keuze die je in een vroeg stadium hebt gemaakt bijzonder waardevol te zijn naarmate er nieuwe use cases opkomen. En we bevinden ons nu in een nieuw tijdperk: het tijdperk van AI.

In dit artikel zal ik onderzoeken wanneer je product OIDC en OAuth 2.0 zou moeten gebruiken, wanneer het deze misschien niet nodig heeft, en waarom ik altijd heb gepleit voor het aannemen van deze open standaarden vanaf het begin — vooral als je een echt bedrijf bouwt en een CIAM-oplossing kiest. Ik zal ook uitleggen waarom de opkomst van AI deze beslissing belangrijker maakt dan ooit.

Wat OAuth 2.0 echt doet (met een eenvoudige analogie)#

Voor lezers die niet heel bekend zijn met OAuth 2.0, laat me even de basisconcepten bekijken — gewoon om de dingen duidelijker te maken.

OAuth 2.0 is voor gedelegeerde autorisatie: OAuth 2.0 is een industrie-standaardprotocol voor autorisatie – het stelt één service in staat om middelen namens een andere service te benaderen met toestemming van de resource-eigenaar.

In een OAuth-scenario verleent de gebruiker (resource-eigenaar) een client-applicatie beperkte toegang (gecoördineerde rechten) tot een API of resource-server, zonder hun wachtwoord te delen. OAuth definieert hoe toegangstokens aangevraagd en uitgegeven moeten worden die de cliënt kan gebruiken om beschermde API's aan te roepen. Dit was een keerpunt vergeleken met de vroege dagen, toen apps je misschien om je inloggegevens vroegen om toegang te krijgen tot een andere service (een ernstig beveiligingsrisico). Met OAuth 2.0 keuren gebruikers specifieke toegang goed en krijgt de cliënt een token met alleen de rechten en duur die nodig zijn — er worden geen wachtwoorden uitgewisseld, wat de beveiliging aanzienlijk verbetert.

Beschouw OAuth 2.0 als het inchecken in een hotel.

Jij (de gebruiker) bent de eigenaar van de kamer (je gegevens). Maar in plaats van iemand je kamersleutel (je wachtwoord) te geven, ga je naar de receptie en vraag je om een tijdelijk toegangskaartje (een toegangstoken) die alleen werkt voor je gast of vriend om de sportschool of het zwembad binnen te komen — niet de hele kamer.

Het hotelpersoneel (OAuth-systeem) geeft deze beperkte kaart uit met specifieke regels:

• Het werkt alleen voor de sportschool (specifieke resource).
• Het is geldig voor een korte tijd.
• Het laat niemand je kamer binnen.

Op deze manier hoef je je hoofdsleutel niet weg te geven — en blijft het systeem veilig, zelfs als iemand anders die beperkte kaart in handen krijgt.

Laten we naar een ander voorbeeld kijken. OAuth 2.0 wordt veel gebruikt in het scenario van sociale inlog.

Stel dat je je aanmeldt voor een nieuwe app zoals Notion, en in plaats van een nieuwe gebruikersnaam en wachtwoord te maken, klik je op “Doorgaan met Google.”

Hier is wat er onder de motorkap gebeurt met OAuth 2.0:

1. Je wordt doorgestuurd naar de inlogpagina van Google, waar je inlogt (als je dat nog niet bent).

2. Google vraagt:

   “Sta je deze app toe om je basisprofiel en e-mailadres te bekijken?”

3. Je klikt op “Toestaan”, en Google stuurt de app een toegangstoken.

4. De app gebruikt dat token om:

   • Je identiteit te bevestigen (via je e-mail en profielinformatie).
   • Je aan te maken of in te loggen op een account — zonder ooit je Google-wachtwoord te zien.

Wat OIDC echt doet (met een eenvoudige analogie)#

Laten we nu eens kijken naar OIDC — een nieuwere en geavanceerdere standaard. OpenID Connect richt zich op Identiteit en Authenticatie: het is een authenticatielaag bovenop OAuth 2.0. Hoewel OAuth 2.0 alleen niet vertelt wie de gebruiker is (het gaat alleen over toegangstokens en scopes), voegt OIDC een standaardmanier toe om met gebruikersinloggen en identiteit om te gaan.

Bij gebruik van OIDC fungeert de autorisatieserver ook als een OpenID Provider (een Identity Provider) die de gebruiker authenticeert en een ID-token uitgeeft met informatie over de gebruiker (de “identiteitsclaims”).

Kortom, OAuth 2.0 antwoordt op “Kan deze cliënt deze resource benaderen?” en OIDC antwoordt op “Wie is de gebruiker die net is ingelogd?”. Samen laten ze je app de identiteit van de gebruiker verifiëren en vervolgens geautoriseerde tokens gebruiken om API's namens de gebruiker te benaderen.

Laten we de Hotel-analogie gebruiken om OAuth 2.0 versus OIDC beter te begrijpen.

Stel je voor dat je incheckt in een hotel.

• OAuth 2.0 is als vragen aan het hotel om je vriend de sportschool en het zwembad te laten gebruiken namens jou.

  Je gaat naar de receptie, geeft toestemming, en het hotel geeft je vriend een gastkaart.

  Het hotel heeft geen interesse in wie de vriend is — alleen dat ze toegang hebben tot de faciliteiten.

  👉 Dat is OAuth: “Deze app kan toegang hebben tot enkele van mijn gegevens of diensten.”

• OIDC is als vragen aan het hotel om te controleren wie de persoon is voordat ze toegang krijgen.

  Dus je vriend laat ook een ID-kaart zien — en nu kent het hotel hun naam, status, en dat ze een geverifieerde gast zijn.

  👉 Dat is OIDC: “Dit is wie de gebruiker is en ze zijn nu ingelogd.”

Hoe Logto gebruik maakt van OAuth 2.0 en OpenID Connect (OIDC)#

Logto’s kernauthenticatiefuncties zijn gebouwd bovenop OIDC (OpenID Connect)#

In de kern is Logto een OpenID Connect (OIDC) provider — een standaard gebouwd bovenop OAuth 2.0 die zich richt op veilige, moderne gebruikersauthenticatie. Logto is een professionele CIAM-oplossing, waar identiteiten de kernbouwstenen zijn die we beheren.

We hebben Logto ontworpen met veiligheid als fundament. Dat betekent het afdwingen van PKCE standaard, het blokkeren van onveilige stromen zoals de impliciete flow, en het vertrouwen op omleiding om inloggen veilig te verwerken.

Waarom omleiding?#

OIDC is bedoeld voor browsergebaseerde authenticatie. Het is niet alleen een technische keuze — het gaat erom gebruikers een veilige, consistente ervaring te geven op alle platforms. De gebruiker doorsturen naar de identity provider (zoals Logto, Google of Microsoft) helpt dat mogelijk te maken.

Hier is hoe de typische flow eruitziet:

1. Gebruiker klikt op “Inloggen”

   → Je app stuurt ze naar de inlogpagina van Logto.

2. Ze loggen veilig in

   → Hier gebeurt de magie met MFA, biometrie, of sociale inlog.

3. Logto stuurt ze terug

   → Samen met een veilig token of autorisatiecode.

4. Je app voltooit de inlog

   → Het token wordt geverifieerd en de gebruiker is ingelogd.

Dit patroon lijkt misschien eenvoudig, maar het biedt krachtige voordelen:

• Je app verwerkt geen inloggegevens direct — wat minder risico betekent.
• Het is makkelijker om functies zoals MFA toe te voegen zonder de app-code te wijzigen.
• Het werkt ook fantastisch voor mobiel:
  • iOS gebruikt ASWebAuthenticationSession.
  • Android gebruikt Custom Tabs.

Als je product diverse apps omvat, maakt Omleiding single sign-on mogelijk — gebruikers loggen eenmalig in en bewegen soepel tussen apps.

Logto ondersteunt het rechtstreeks in je app verzamelen van wachtwoorden niet. Dat is met opzet. De ROPC flow wordt niet aanbevolen voor OAuth 2.0 beveiligingspraktijken om goede redenen — het is minder veilig en moeilijker veilig te schalen.

Logto is ook een OAuth 2.0/OIDC provider (Identity Provider)#

Logto is meer dan alleen een authenticatieserver — het is een volledige OAuth 2.0, OpenID Connect (OIDC), en Identity Provider (IdP). Dit betekent dat het gebruikersidentiteiten veilig kan beheren en tokens kan uitgeven die door andere applicaties kunnen worden vertrouwd.

Naast dat het de inlogervaringen voor je eigen apps mogelijk maakt, ondersteunt Logto ook integraties met derden, waardoor externe services op Logto als hun identiteit kunnen vertrouwen.

Wat betekent dat in de praktijk?

Als een Identity Provider (IdP), verwerkt Logto gebruikersverificatie, beheert inloggegevens en geeft authenticatietokens uit. Zodra een gebruiker inlogt, kan Logto ze toegang verlenen tot verschillende apps — zelfs van andere leveranciers — zonder opnieuw in te loggen. Het is hetzelfde concept als “Inloggen met Google” of “Inloggen met Microsoft”.

Er zijn twee soorten applicaties in deze context:

• First-party apps: Apps die je bouwt en volledig controleert, direct geïntegreerd met Logto.
• Derden-apps: Externe services gebouwd door partners of ontwikkelaars buiten je organisatie.

Logto stelt je gebruikers in staat om bij deze derde-partij-apps in te loggen met hun bestaande Logto-accounts — net zoals ondernemingsgebruikers inloggen bij tools als Slack met hun Google Workspace-gegevens. Dit stelt je in staat om:

• Single sign-on (SSO) te bieden in je ecosysteem.
• Een open platform te bouwen, waar externe ontwikkelaars “Inloggen met Logto” aan hun apps kunnen toevoegen.

Wanneer heb je echt OAuth 2.0 en OIDC nodig?#

1. Als je eerder Auth0 (of vergelijkbaar) gebruikte: Auth0 is al een OAuth 2.0- en OIDC-provider. Het beheert gebruikersinlog, tokenuitgifte, en integreert met je API's of apps.
2. M2M-autorisatie: Server-naar-server (client credentials flow) Machines (of backend-diensten) moeten veilig communiceren zonder een gebruiker.
3. Apparaatflow: Slimme tv's, consoles, IoT-apparaten: Apparaten zoals tv's of printers moeten een gebruiker authenticeren. Apparaatflow maakt deel uit van de OIDC.
4. Je hebt integratiebehoeften: Je doet meer dan alleen gebruikers authenticeren — je creëert een ecosysteem waar externe apps, partners of agents veilig met je platform kunnen integreren en gebruikersgegevens kunnen openen.

Waarom OAuth en OIDC belangrijker zijn dan ooit in het AI tijdperk#

In het AI tijdperk zien we een groeiende behoefte aan nieuwe integratie- en toegangsbehoeften — vooral in gebieden zoals autonome agents, slimme apparaten, en systeem-naar-systeemcommunicatie. Deze trends maken OAuth 2.0 en OIDC belangrijker dan ooit. Hier zijn een paar voorbeelden:

1. Remote MCP-servers

   Je bouwt een remote MCP (Model Context Protocol)-server en wilt dat derde-partij-agents ermee verbinding maken. Deze agents hebben veilige toegang nodig om context aan te vragen, acties uit te voeren en gegevens uit te wisselen — zonder het vertrouwen van gebruikers in gevaar te brengen. OAuth biedt het mechanisme om toegang veilig te delegeren.

2. Je product openstellen voor integraties

   Je runt je eigen bedrijf services — zeg een projectmanagementtool of een klantplatform — en je wilt dat andere producten of agents ermee kunnen integreren. Dat kan betekenen dat gegevens worden opgehaald, workflows worden geactiveerd, of je functies worden ingebed in andere omgevingen. OAuth 2.0/OIDC maakt gedetailleerde, tokengebaseerde toegangscontrole mogelijk zonder gebruikersgegevens te delen.

3. Je eigen agent bouwen

   Je maakt een AI-agent of assistent en wilt dat hij interactie heeft met andere apps en MCP-servers — vergaderingen plannen, e-mails verzenden, updates plaatsen, of gegevens opvragen. Deze vereisen veilige, geauthenticeerde toegang tot derde-partijservices. OAuth 2.0 is hoe je agent gemachtigd wordt om namens de gebruiker te handelen.

4. De opkomst van slimme apparaten

   Hardware-apparaten zoals AI-vertalers of slimme notitienemers voor vergaderingen worden steeds capabeler dankzij LLMs. En met lagere kosten en hogere prestaties komen steeds meer van deze apparaten op de markt. Deze apparaten hebben vaak een manier nodig om gebruikers te authenticeren en toegang te krijgen tot cloud-gebaseerde services — vooral met beperkte invoerinterfaces. Dat is waar flows zoals OAuth's apparaat-autorisatieflow en OIDC-gebaseerde identiteitsvalidatie cruciaal worden.

Wanneer je misschien geen OAuth 2.0/OIDC nodig hebt#

Natuurlijk, er zijn gevallen waarin je misschien geen OAuth 2.0 of OIDC nodig hebt — tenminste voor nu. Met andere woorden, als je huidige use case simpel of volledig zelfvoorzienend is, kunnen deze protocollen op korte termijn geen directe waarde opleveren.

Echter, naarmate je product groeit of je ecosysteem uitbreidt, wordt de behoefte aan OAuth 2.0 en OIDC op de lange termijn vaak veel duidelijker.

1. Eenvoudige, interne apps

   Als je app alleen gebruikt wordt door een klein team binnen een bedrijf en niet hoeft te integreren met third-party-services of APIs te openen, kan een basissysteem met gebruikersnaam-wachtwoord-authenticatie (bijv. cookiesessies) voldoende zijn.

2. Geen gebruikersauthenticatie nodig

   Als je product geen gebruikersaccounts of identiteitsbewuste kenmerken heeft—zoals een publieke inhoudssite of een server-naar-server-tool met statische API-sleutels—is OIDC niet nodig.

3. Geen gedelegeerde toegang vereist

   OAuth schittert wanneer je gebruikers wilt laten autoriseren dat je app toegang krijgt tot hun gegevens in een ander systeem (bijv. Google Drive). Als je niet integreert met third-party-API's of mult...