Wat is authenticatie? Inloggen, sessies en OAuth uitgelegd

Authenticatie is hoe een app vaststelt wie een gebruiker is — meestal door iets te controleren wat die weet (een wachtwoord), iets wat die bezit (een code op zijn telefoon of e-mail) of een identiteit van een andere betrouwbare dienst (zoals ‘Inloggen met Google’). Zodra een gebruiker is geauthenticeerd, onthoudt de app die met een sessie of token, zodat die niet bij elke pagina opnieuw hoeft in te loggen. Bepalen wat die bekende gebruiker mag doen is een aparte stap, autorisatie genoemd.

Waarom het ertoe doet als je met AI bouwt

Inloggen toevoegen is een van de meest voorkomende verzoeken aan een AI-appbouwer, en een van de makkelijkst subtiel fout te doen. Een inlogpagina genereren is eenvoudig. Het moeilijke is alles eromheen:

• Worden wachtwoorden veilig opgeslagen?
• Controleert elke privépagina en elk API-eindpunt echt wie er vraagt?
• Kan een ingelogde klant de gegevens van een andere klant zien door een getal in de URL te veranderen?
• Wat gebeurt er als iemand zijn wachtwoord vergeet?

Een app kan er volkomen veilig uitzien terwijl hij op al die punten faalt. Als je de bewegende delen begrijpt, kun je de juiste vragen stellen en de juiste dingen testen.

Een alledaagse vergelijking

Denk aan inchecken in een hotel.

Bij de receptie laat je je ID zien. Dat is authenticatie: bewijzen wie je bent. De receptionist geeft je vervolgens een sleutelpasje. Die pas is je sessie: voor de rest van je verblijf laat je je ID niet meer zien; je houdt alleen de pas tegen de lezer.

De pas opent je kamer, de sportschool en de lift naar je verdieping — maar niet de kamers van andere gasten of het personeelskantoor. Dat is autorisatie: wat je identiteit mag openen. Als je de pas verliest, kan het hotel die bij de balie deactiveren (een sessie intrekken). Bij het uitchecken werkt hij niet meer (uitloggen of verlopen).

‘Inloggen met Google’ is alsof een hotel een brief van een vertrouwde partner accepteert waarin staat ‘dit is wie hij is’, in plaats van zelf je ID te controleren.

De belangrijkste inlogmethoden

Hoe wachtwoorden moeten worden opgeslagen

Een veilige app slaat je werkelijke wachtwoord nooit op. In plaats daarvan slaat hij een hash op: de uitkomst van een eenrichtingsfunctie die het wachtwoord omzet in een vaste reeks tekens. Wanneer je inlogt, hasht de app wat je hebt getypt en vergelijkt het resultaat met de opgeslagen hash.

Twee details maken dit veilig:

• Een salt — een willekeurige waarde die aan elk wachtwoord wordt toegevoegd vóór het hashen, zodat twee mensen met hetzelfde wachtwoord verschillende hashes krijgen en vooraf berekende opzoektabellen nutteloos zijn.
• Een traag algoritme dat voor wachtwoorden is gemaakt — zoals Argon2, bcrypt of scrypt. Algemene hashes zoals MD5 of SHA-256 zijn op zichzelf veel te snel; aanvallers kunnen miljarden gissingen proberen.

Hashen is niet hetzelfde als versleutelen. Versleutelde gegevens kunnen met een sleutel worden ontsleuteld; een wachtwoord-hash is juist ontworpen om helemaal niet omkeerbaar te zijn.

Sessies vs tokens

Na het inloggen moet de app je bij elk verzoek herkennen. Er zijn twee veelgebruikte aanpakken.

Voor cookies zijn drie instellingen belangrijk: HttpOnly (JavaScript op de pagina kan de cookie niet lezen), Secure (alleen via HTTPS verzonden) en SameSite (beperkt het verzenden bij verzoeken vanaf andere sites). Tokens in de localStorage van de browser opslaan is gebruikelijk, maar stelt ze bloot aan elk script dat op de pagina draait.

OAuth en ‘Inloggen met Google’

OAuth 2.0 is een standaard voor gedelegeerde autorisatie: het laat een app beperkte toegang krijgen tot je account bij een andere dienst — bijvoorbeeld om je Google Agenda te lezen — zonder ooit je Google-wachtwoord te zien. Je wordt naar Google gestuurd, keurt specifieke rechten goed (scopes genoemd), en Google geeft de app een token voor alleen die rechten.

OAuth alleen is bedoeld om toegang te verlenen, niet om te zeggen wie je bent. OpenID Connect (OIDC) is een laag bovenop OAuth 2.0 die identiteit toevoegt; dat gebruikt ‘Inloggen met Google’ of ‘Inloggen met Apple’. Om het in te stellen registreer je je app bij de aanbieder en krijg je een client-ID en een client-secret; het secret blijft op je server.

Een uitgewerkt voorbeeld: inloggen voor een klantenportaal

Stel dat je een portaal bouwt waar klanten van een ontwerpbureau hun projecten en facturen zien.

• Authenticatie: klanten loggen in met e-mail en een magic link, zodat er geen wachtwoorden hoeven te worden beheerd. Medewerkers van het bureau loggen in met Google Workspace-accounts.
• Rollen: elke gebruiker heeft een rol — client of staff.
• Autorisatieregels:

• Waar het wordt afgedwongen: op de server, bij elk verzoek. De server zoekt de ingelogde gebruiker op en geeft alleen projecten terug waarbij project.company_id overeenkomt met het bedrijf van de gebruiker. De knop ‘Markeer als betaald’ verbergen is niet genoeg — het eindpunt zelf moet weigeren.

Veelgebruikte termen uitgelegd

Veelgemaakte fouten en misverstanden

• Rechten alleen in de pagina controleren. Als de browser een knop verbergt maar de API niet controleert, kan iedereen de API direct aanroepen.
• Vertrouwen op ID's uit de URL. /invoices/1042 moet controleren dat factuur 1042 bij de ingelogde gebruiker hoort.
• Eigen cryptografie bouwen. Gebruik bekende bibliotheken of aanbieders; laat de AI geen hashmethode verzinnen.
• Zwakke wachtwoordreset. Resetlinks moeten eenmalig zijn, snel verlopen en niet onthullen of een e-mailadres een account heeft.
• Je login verwarren met die van je bouwtool. De gebruikers van je app zijn los van je account bij de tool waarmee je bouwt.
• Geen rate limiting op inloggen. Zonder dat kunnen aanvallers eindeloos wachtwoorden proberen.

Wat je aan je AI-appbouwer kunt vragen

• ‘Voeg aanmelden en inloggen toe met [een bekende bibliotheek of aanbieder]. Schrijf geen eigen wachtwoord-hashing.’
• ‘Sla wachtwoorden gehasht op met bcrypt of Argon2.’
• ‘Gebruik HttpOnly- en Secure-cookies voor de sessie.’
• ‘Voeg rollen toe: admin en member. Geef een lijst van elk eindpunt en welke rollen het mogen aanroepen.’
• ‘Dwing op de server af dat gebruikers alleen hun eigen gegevens kunnen lezen en wijzigen. Laat me daarna zien hoe je dat hebt gecontroleerd.’
• ‘Voeg wachtwoordreset toe met eenmalige links die na een uur verlopen.’
• ‘Beperk het aantal inlogpogingen.’

Test het daarna zelf: maak twee accounts aan en probeer terwijl je bent ingelogd als de ene de gegevens van de andere te bereiken. Onze gids voor het toevoegen van inloggen en beveiligingschecklist gaan verder.

Authenticatie in Mythex

Mythex biedt geen ingebouwd authenticatieproduct voor de gebruikers van je app; jij kiest een aanpak — e-mail en wachtwoord opgeslagen in de database van je project, of de SDK van een gehoste aanbieder — en vraagt de agent die toe te voegen. Sleutels van aanbieders gaan in projectgeheimen, niet in de chat. Dit staat los van hoe je zelf inlogt bij Mythex. Het docs-recept over inloggen aan je app toevoegen heeft een startprompt die je kunt aanpassen, en wat een API is legt uit waar die serverzijdige controles leven.

Veelgestelde vragen