Hoe voeg je authenticatie toe aan een AI-gegenereerde app

Een AI-appbouwer kan in seconden een inlogscherm opzetten. Maar gebruikers inloggen is het makkelijke deel. Het lastige, beveiligingskritische deel is ervoor zorgen dat elke geauthenticeerde gebruiker alleen zijn eigen gegevens kan zien. Deze gids doorloopt het correct toevoegen van authenticatie aan een AI-gegenereerde app en markeert de exacte plekken waar gegenereerde code tekortschiet.

Authenticatie versus autorisatie: ken het verschil

Deze twee woorden klinken hetzelfde en worden voortdurend verward, ook door codegeneratoren.

• Authenticatie beantwoordt "wie ben jij?" Het verifieert identiteit: een correct wachtwoord, een geldige magische link, een Google-inlog.
• Autorisatie beantwoordt "wat mag je doen?" Het beslist of de ingelogde gebruiker deze factuur mag lezen, dat record mag bewerken of het account van een andere gebruiker mag verwijderen.

Hier is het patroon dat het meest van belang is in dit artikel: AI-tools implementeren betrouwbaar authenticatie en verprutsen vaak autorisatie. Een gegenereerde app toont vrolijk een inlogformulier, geeft een sessie en begroet je bij naam, maar laat toch elke ingelogde gebruiker ophalen iedereens gegevens door een ID in de URL te wijzigen. Houd die foutmodus in gedachten terwijl we verder gaan.

Kies een authenticatiemethode

Kies op basis van je gebruikers en bedreigingsmodel, niet op wat de generator standaard heeft ingesteld.

• E-mail en wachtwoord — vertrouwd en zelfstandig, maar je draagt de last van hashing, reset-stromen en inbreukrespons.
• Magische links — een eenmalige ondertekende URL die naar de gebruiker wordt gemaild. Geen wachtwoord om te lekken. De afweging is e-mailbezorgbaarheid en korte linkvervaltijd.
• OAuth / sociale login — "Inloggen met Google/GitHub." Je delegeert credential-afhandeling aan een provider. Verifieer de geretourneerde e-mail en accountstatus; vertrouw nooit een ID-token dat je niet hebt gevalideerd.
• SSO (SAML / OIDC) — verwacht door zakelijke kopers die centrale controle willen. Meestal een latere toevoeging, maar ontwerp je gebruikersmodel zodat het kan worden ingepast.

Het aanbieden van meer dan één methode is prima. Zorg er alleen voor dat ze uitkomen op één enkele canonieke gebruikerrecord, zodat een persoon die zich aanmeldt met een wachtwoord en later Google gebruikt, niet eindigt met twee accounts.

Sessies versus tokens

Zodra de identiteit is geverifieerd, moet je deze onthouden bij meerdere verzoeken. Twee gangbare benaderingen:

1. Server-sessies — de server slaat sessiestatus op en geeft de browser een ondoorzichtige sessie-ID in een cookie. Makkelijk in te trekken: verwijder de server-side record en de sessie is dood.
2. Staatloze tokens (JWT) — een ondertekend token bevat claims (gebruikers-ID, vervaldatum). Er wordt niets server-side opgeslagen, wat goed schaalt maar het direct intrekken moeilijker maakt. Een gelekt, niet-verlopen token blijft geldig tot het verloopt.

Voor de meeste maker- en SaaS-apps zijn server-sessies of kortlevende tokens gekoppeld aan een vernieuwingstoken de veiligere standaard. Wat de generator ook heeft geproduceerd, bevestig dat je daadwerkelijk een gebruiker overal uitloggen en een gecompromitteerd credentiaal ongeldig maken.

Veilige cookie-vlaggen zijn niet onderhandelbaar

Hoe je de sessie-identificatie ook levert, stel de cookie correct in. Gegenereerde code laat deze vaak weg:

• HttpOnly — blokkeert JavaScript om de cookie te lezen, waardoor diefstal via XSS wordt beperkt.
• Secure — de cookie wordt alleen via HTTPS verzonden.
• SameSite — Lax or Strict to reduce CSRF exposure.
• Een redelijke vervaldatum en een nieuwe sessie-ID bij inloggen om sessiefixatie te voorkomen.

Never put a JWT or session token in localStorage if you can use an HttpOnly cookie instead; storage that scripts can read is storage an XSS bug can steal.

Wachtwoorden correct hashen

Als je wachtwoorden accepteert, sla dan alleen een trage, gezouten hash op. Gebruik een speciaal gebouwd wachtwoord-hash-algoritme zoals bcrypt, scrypt of Argon2. Gebruik geen MD5, SHA-256 of een snelle algemene hash voor wachtwoorden, en sla nooit platte tekst op.

• Laat de bibliotheek een uniek zout per wachtwoord genereren.
• Vergelijk met de constant-time verify-functie van de bibliotheek.
• Vertrouw op gepubliceerde, huidige standaardwaarden voor werkfactoren in plaats van je eigen te bedenken.

Dit is specifiek de moeite waard om te controleren, omdat een ogenschijnlijk plausibel gegenereerd fragment stilletjes naar een snelle hash kan grijpen. Controleer bij het beoordelen van gegenereerde authenticatiecode zwak hashen als een release-blocker. Onze beveiligingsauditgids voor AI-gegenereerde apps behandelt hoe je systematisch naar deze patronen kunt greppen.

Wachtwoordreset zonder een gat te openen

Resetstromen zijn een klassiek zwak punt. Bouw ze defensief:

• Genereer een willekeurig, eenmalig token gekoppeld aan het account, en sla alleen de hash ervan op.
• Geef het een korte vervaldatum (bijvoorbeeld een uur) en maak het ongeldig zodra het is gebruikt.
• Geef het zelfde antwoord of het e-mailadres nu wel of niet bestaat, zodat het eindpunt niet kan worden gebruikt om accounts op te sommen.
• Rate-limit resetverzoeken en vereis herauthenticatie voor gevoelige wijzigingen zoals het wijzigen van het account-e-mailadres.

Rolgebaseerde toegangscontrole

De meeste apps hebben meer nodig dan "ingelogd of niet." Definieer expliciete rollen (bijvoorbeeld, admin, member, viewer) en controleer ze op de server voor elke beveiligde actie. Twee regels houden dit eerlijk:

• Autorisatie afdwingen op de server, nooit alleen door knoppen in de UI te verbergen. Verborgen UI is een gemak, geen controle.
• Standaard naar deny. Een nieuw eindpunt moet ontoegankelijk zijn totdat je expliciet toegang verleent, niet open totdat iemand eraan denkt het te vergrendelen.

Als je iets bouwt met duidelijke rolniveaus, zoals een CRM gebouwd met AI, modelleer de rollen voordat je de eindpunten genereert, zodat toegangsregels erin zijn verwerkt in plaats van achteraf worden toegevoegd.

De stap die AI meestal overslaat: objectniveau-toegang testen

Dit is de belangrijkste test in dit artikel. Objectniveau-autorisatie (vaak IDOR genoemd wanneer het ontbreekt) betekent controleren dat deze gebruiker eigenaar is van of toegang heeft tot dit specifieke record, niet alleen dat ze zijn ingelogd.

Test het direct:

1. Maak twee accounts aan, Gebruiker A en Gebruiker B.
2. Maak als Gebruiker A een record aan en noteer de ID.
3. Log in als Gebruiker B en vraag het record van Gebruiker A op via die ID, via de API en door URL's te bewerken.
4. Gebruiker B moet een 403 of 404 krijgen — nooit de gegevens van Gebruiker A.

Herhaal voor read, update en delete voor elk resourcetype. Gegenereerde code controleert vaak de sessie maar vergeet de eigenaarsclausule in de query, dus deze eenvoudige twee-account-test vangt een groot deel van echte kwetsbaarheden op. Neem het op in je pre-implementatie checklist voor AI-apps.

Alles samenbrengen

Laat de builder de inlogschermen en bedrading opzetten; dat bespaart echte tijd. Besteed dan je inspanning waar het risico geconcentreerd is: cookie-vlaggen, wachtwoordhashing, reset-token hygiëne, rolcontroles en bovenal objectniveautoegang. Als je afweegt of gegenereerde output klaar is om uit te rollen, onze visies op of AI-gegenereerde apps productieklaar zijn en het bouwen van een SaaS MVP met AI plaatsen dit werk in context.

Auth is een van de weinige gebieden waar "het werkt als ik er doorheen klik" niet goed genoeg is. Verifieer de grenzen, niet alleen het happy path, en je kunt gegenereerde auth met vertrouwen uitrollen. Klaar om te bouwen? Begin met LogicMint.