API-authenticatie bepaalt welke toepassing of gebruiker toegang krijgt tot een API en welke acties zijn toegestaan. Dit artikel legt uit hoe API-sleutels, OAuth 2.0 en serviceaccounts van elkaar verschillen, en behandelt tokenbeheer, scopes, rotatie en veelvoorkomende beveiligingsfouten.
API-authenticatie begint bij identiteit en toegangsmodel
Een API moet niet alleen vaststellen of een verzoek een geldig geheim bevat, maar ook namens wie het verzoek wordt gedaan en welke gegevens toegankelijk mogen zijn. Dat onderscheid bepaalt welke authenticatiemethode past. Een integratie die gegevens uitwisselt tussen twee systemen heeft een ander toegangsmodel dan een toepassing waarin individuele gebruikers hun eigen accountgegevens opvragen.
Maak daarom onderscheid tussen authenticatie en autorisatie. Authenticatie stelt de identiteit van een gebruiker, toepassing of workload vast. Autorisatie bepaalt wat die identiteit vervolgens mag doen. Een geldige API-sleutel kan bijvoorbeeld een toepassing identificeren, maar geeft op zichzelf niet altijd een beperkte set rechten aan. OAuth 2.0 combineert doorgaans een token met scopes of andere beleidsregels om die rechten te begrenzen.
Breng vóór de keuze van een methode in kaart wie het verzoek initieert, hoe lang toegang nodig is, welke gegevens beschikbaar zijn en waar geheimen worden opgeslagen. Houd ook rekening met de omgeving: een sleutel in een serverproces is anders te beschermen dan een sleutel in JavaScript dat naar iedere browser wordt gestuurd. Wanneer een geheim niet geheim kan blijven, is het geen geschikte methode om een vertrouwde serveridentiteit te bewijzen.
De praktische keuze is dus geen ranglijst van technieken. Het gaat om de aansluiting tussen identiteit, rechten, levensduur van toegang en de plek waar de toepassing draait. Een eenvoudige machine-integratie kan prima met een API-sleutel werken, terwijl gedelegeerde toegang namens gebruikers meestal een OAuth-stroom nodig heeft.
API-sleutels: geschikt voor eenvoudige systeemintegraties
Een API-sleutel is doorgaans een lange, willekeurige tekenreeks die een toepassing meestuurt met een verzoek. De API zoekt de sleutel op, koppelt die aan een project of integratie en bepaalt op basis daarvan of het verzoek wordt geaccepteerd. Dit model is gemakkelijk te implementeren en past bij server-naar-serverintegraties waarbij een toepassing toegang nodig heeft tot één afgebakende API.
De eenvoud heeft een keerzijde: een sleutel vertegenwoordigt meestal geen individuele gebruiker en bevat vaak weinig context over het specifieke verzoek. Als meerdere processen dezelfde sleutel delen, is achteraf moeilijk vast te stellen welk proces toegang gebruikte. Een gelekte sleutel kan bovendien geldig blijven totdat iemand hem intrekt of vervangt. Sommige API’s bieden aanvullende beperkingen, zoals toegestane IP-adressen, quota of toegang tot bepaalde endpoints. Gebruik die mogelijkheden, maar beschouw ze niet als vervanging voor geheimbeheer.
Stuur een API-sleutel niet mee in queryparameters. URL’s komen vaak terecht in serverlogs, browsergeschiedenis, analytics en foutmeldingen. Gebruik de door de API voorgeschreven header en voorkom dat die header in applicatielogs wordt vastgelegd. Een sleutel hoort evenmin in broncode, mobiele apps of frontendbundels: gebruikers kunnen die bestanden inspecteren en de waarde kopiëren.
API-sleutels zijn minder geschikt wanneer gebruikers afzonderlijk toestemming moeten geven, wanneer rechten per gebruiker verschillen of wanneer toegang automatisch kort moet verlopen. In zulke gevallen levert een tokenmodel met expliciete autorisatie meer controle op. De keuze voor een sleutel is verantwoord wanneer de identiteit van de integratie volstaat en de sleutel veilig beheerd en snel ingetrokken kan worden.
OAuth 2.0 voor toegang namens een gebruiker
OAuth 2.0 is een autorisatieframework waarmee een toepassing beperkte toegang kan krijgen tot een API. Bij toegang namens een gebruiker wordt die gebruiker doorgaans naar een autorisatieserver geleid, meldt zich daar aan en verleent toestemming aan de toepassing. De toepassing ontvangt vervolgens een access token waarmee zij toegestane API-verzoeken kan uitvoeren. Het wachtwoord van de gebruiker wordt daarbij niet aan de toepassing verstrekt.
Voor web- en mobiele toepassingen die gebruikersaccounts gebruiken, is Authorization Code met PKCE de gangbare keuze. De toepassing ontvangt eerst een tijdelijke authorization code en wisselt die in voor tokens. PKCE bindt die uitwisseling aan de oorspronkelijke aanvraag en verkleint de kans dat een onderschepte code door een andere partij kan worden gebruikt. Een vertrouwelijke servertoepassing kan daarnaast een client secret gebruiken, maar dat geheim moet op de server blijven en is geen veilige opslagmethode voor een browserapp.
Een OAuth-flow vraagt om een correcte omgang met redirect-URI’s, state en tokenopslag. Redirect-URI’s moeten exact overeenkomen met vooraf geregistreerde adressen; ruime wildcardregels kunnen een aanvaller ruimte geven om een code naar een eigen bestemming te sturen. De state-waarde helpt aanvragen aan een gebruikerssessie te koppelen en beschermt tegen vervalste terugkeer naar de toepassing. Tokens horen niet in URL’s of onbeveiligde browseropslag.
OAuth 2.0 beschrijft autorisatie, niet op zichzelf de manier waarop een API de identiteit van een gebruiker verifieert. OpenID Connect voegt daar een identiteitslaag aan toe, onder meer met een ID-token. Verwissel een ID-token niet met een access token: ze hebben een ander doel en zijn bedoeld voor verschillende ontvangers.
Serviceaccounts voor geautomatiseerde processen
Een serviceaccount is een identiteit voor software in plaats van voor een menselijke gebruiker. Denk aan een geplande taak die bestanden verwerkt, een backend die gegevens synchroniseert of een workload die een cloudservice aanroept. Het serviceaccount maakt het mogelijk om rechten aan een specifieke functie toe te kennen en activiteiten aan die identiteit toe te schrijven, zonder een persoonlijk gebruikersaccount te gebruiken.
De term heeft niet bij iedere leverancier exact dezelfde betekenis. In de ene omgeving is een serviceaccount een afzonderlijk account waaraan langlevende sleutels gekoppeld kunnen worden. In een andere omgeving verkrijgt de workload tijdelijk credentials via de infrastructuur waarop zij draait. OAuth 2.0 Client Credentials is een veelgebruikte stroom voor toegang van een toepassing tot een API zonder gebruiker. De toepassing authenticeert zichzelf bij de autorisatieserver en ontvangt een access token. Een serviceaccount kan de identiteit achter zo’n stroom zijn, maar de begrippen zijn niet onderling uitwisselbaar.
Geef elk proces een eigen identiteit in plaats van één account voor alle automatisering te gebruiken. Daarmee kan toegang per workload worden beperkt en is bij incidenten duidelijker welke integratie geraakt is. Wijs alleen rechten toe die nodig zijn voor de concrete taak; een proces dat records leest, heeft geen schrijfrechten nodig. Waar de infrastructuur tijdelijke credentials kan uitgeven, verdient dat meestal de voorkeur boven een gedownloade, langdurig geldige sleutel.
Serviceaccounts horen niet te worden gebruikt om menselijke gebruikers te omzeilen. Als een handeling namens een gebruiker plaatsvindt en afhankelijk is van diens toestemming, past gedelegeerde OAuth-toegang beter. Het onderscheid tussen een workloadidentiteit en een gebruikersidentiteit maakt beleid, controle en incidentonderzoek aanzienlijk nauwkeuriger.
Scopes, claims en doelbinding beperken API-rechten
Een credential bewijst niet automatisch dat een toepassing toegang tot alle functies van een API nodig heeft. Scopes leggen vast welke categorieën acties een OAuth-token mag uitvoeren, bijvoorbeeld alleen gegevens lezen of ook gegevens aanpassen. Een autorisatieserver kan de gevraagde scopes toetsen aan beleid en eventueel aan de toestemming van de gebruiker. De API moet die scopes vervolgens daadwerkelijk controleren; het opnemen van een scope in een token beperkt niets als de ontvangende dienst die waarde negeert.
Vraag alleen de rechten aan die de toepassing nodig heeft. Een brede scope zoals volledige accounttoegang vergroot de schade bij diefstal van een token en maakt het lastiger om aan gebruikers uit te leggen waarvoor toestemming wordt gegeven. Splits rechten waar dat aansluit op concrete functies, zoals lezen, schrijven of toegang tot een bepaald gegevensdomein. Houd er rekening mee dat scopes niet altijd hetzelfde zijn als rollen: een scope beschrijft vaak een type API-toegang, terwijl rollen gebruikers of processen binnen een bedrijfsmodel indelen.
Ook doelbinding is belangrijk. Een token dat voor de ene API bedoeld is, mag niet automatisch bij een andere API worden geaccepteerd. Claims zoals issuer, audience en vervaltijd helpen de ontvanger controleren waar het token vandaan komt, voor wie het bestemd is en hoe lang het bruikbaar blijft. De API moet deze waarden valideren en niet uitsluitend vertrouwen op een token dat cryptografisch geldig lijkt.
Een praktische controle omvat zowel de rechten in het token als het beleid van de API. Controleer bij iedere gevoelige bewerking of de identiteit, scope, tenant en resource overeenkomen met de gevraagde actie. Alleen controleren of een gebruiker is ingelogd of een token aanwezig is, is onvoldoende voor toegang tot specifieke gegevens.
Access tokens en refresh tokens veilig beheren
Een access token is bedoeld voor toegang tot een API en heeft doorgaans een beperkte geldigheidsduur. Een refresh token kan worden gebruikt om nieuwe access tokens aan te vragen zonder dat de gebruiker telkens opnieuw toestemming verleent. Dat maakt refresh tokens aantrekkelijk voor gebruiksgemak, maar ook gevoeliger: wie een refresh token buitmaakt, kan mogelijk gedurende langere tijd nieuwe toegang verkrijgen.
Bewaar tokens op basis van het type toepassing. Een backend kan tokens in een beveiligde server-side sessie opslaan, buiten broncode en logs. Een browserapp kan een access token in het geheugen houden en een backend gebruiken om langduriger credentials af te schermen. Mobiele apps kunnen gebruikmaken van de beveiligde opslagvoorzieningen van het besturingssysteem. Geen enkele opslagmethode is zonder risico; voorkom in elk geval dat tokens in queryparameters, analytics, foutmeldingen of onbeveiligde gedeelde opslag belanden.
Stel de geldigheidsduur af op het risico en de gebruikssituatie. Een kortlevend access token beperkt de periode waarin een gelekt token bruikbaar is, maar betekent wel vaker vernieuwen. Gebruik waar mogelijk refresh-tokenrotatie: na gebruik wordt een nieuw refresh token uitgegeven en het oude ongeldig gemaakt. Als een oud token opnieuw verschijnt, kan dat wijzen op kopiëren of hergebruik. De autorisatieserver kan dan de tokenfamilie intrekken, afhankelijk van het gebruikte beleid.
Plan ook voor intrekking en sessiebeëindiging. Een access token dat lokaal door een API wordt gevalideerd, blijft vaak geldig tot de vervaltijd, tenzij aanvullende intrekkingscontrole bestaat. Bij gevoelige systemen kan een korte levensduur, introspectie of een denylist nodig zijn. Log tokengebruik zonder de tokenwaarde zelf vast te leggen; registreer bijvoorbeeld de clientidentiteit, scope en uitkomst van de aanvraag.
Geheimen roteren zonder integraties uit het oog te verliezen
Rotatie is het vervangen van een credential voordat of nadat de oude waarde niet langer vertrouwd wordt. API-sleutels, client secrets en handtekeningsleutels kunnen uitlekken door codebeheer, verkeerd ingestelde cloudopslag, logging of toegang van medewerkers. Een credential die nooit wordt vervangen, kan lang na een oorspronkelijke wijziging nog toegang geven. Rotatie verkleint die blootstellingsduur, maar vereist een proces dat afhankelijkheden en actief gebruik zichtbaar maakt.
Een gecontroleerde sleutelrotatie gebruikt waar mogelijk een periode waarin zowel de oude als de nieuwe credential geldig zijn. Maak eerst de nieuwe waarde aan, sla deze op in de juiste secret manager en laat de toepassing ermee authenticeren. Controleer vervolgens in logs of de nieuwe credential wordt gebruikt en trek de oude in. Sommige aanbieders ondersteunen meerdere actieve sleutels; andere vereisen een omschakeling zonder overlap. In dat laatste geval moet de toepassing zorgvuldig worden uitgerold om foutieve configuratie en onverwachte uitval te voorkomen.
Houd een inventaris bij van credentials, eigenaren, gekoppelde diensten en gebruiksdoelen. Zonder die informatie is het lastig te bepalen welke sleutel veilig kan worden ingetrokken. Detectie helpt: ongebruikte sleutels, onverwachte locaties en afwijkende aanvraagvolumes verdienen onderzoek. Geheimen horen in een secret manager of een vergelijkbare gecontroleerde voorziening, niet in een repository, configuratiebestand dat breed wordt gedeeld of containerimage.
Automatische rotatie kan fouten verminderen, maar werkt alleen als de toepassing nieuwe waarden kan ophalen en oude waarden correct afhandelt. Test daarom ook wat er gebeurt bij een verlopen, ingetrokken of tijdelijk onbereikbaar geheim. Rotatie zonder monitoring en intrekkingsprocedure is slechts een wijziging van een tekenreeks, geen volwassen beheer van API-toegang.
Veelvoorkomende fouten bij API-authenticatie voorkomen
Een veelvoorkomende fout is een geheim opnemen in frontendcode, een mobiele applicatie of een openbare repository. Alles wat naar een client wordt gestuurd, kan door gebruikers worden teruggevonden. Ook privé-repositories sluiten lekkage niet uit: credentials kunnen in commits, buildlogs, foutmeldingen of kopieën van configuratiebestanden blijven staan. Trek een blootgesteld geheim in; alleen de waarde uit de huidige broncode verwijderen maakt eerdere kopieën niet ongeldig.
Een tweede fout is tokens en sleutels onbedoeld loggen. HTTP-headers kunnen automatisch worden opgenomen door proxies, tracingsoftware en applicatielogs. Stel redactie in voor autorisatieheaders en gevoelige velden, en controleer dat foutmeldingen geen volledige aanvraagheaders teruggeven. Verstuur credentials uitsluitend via versleutelde verbindingen en gebruik niet de URL als drager, omdat URL’s op veel plaatsen worden opgeslagen.
Ook te ruime rechten en gedeelde accounts bemoeilijken beveiliging. Als een API-sleutel alle endpoints ontsluit of één serviceaccount door meerdere processen wordt gebruikt, neemt de impact van een lek toe en wordt onderzoek minder precies. Beperk rechten per toepassing, omgeving en functie. Gebruik afzonderlijke credentials voor ontwikkeling, test en productie, zodat een testomgeving niet ongemerkt toegang krijgt tot productiedata.
Controleer ten slotte de validatie aan de API-kant. Een API moet onder meer de handtekening of sleutel controleren, de vervaltijd en doelgroep van een token valideren en de gevraagde actie autoriseren. Vertrouw niet op gegevens die een client zelf aanlevert om zijn identiteit of rechten te onderbouwen. Test negatieve scenario’s expliciet: verlopen tokens, verkeerde scopes, onbekende issuers, ingetrokken sleutels en verzoeken voor gegevens van een andere gebruiker moeten worden afgewezen zonder gevoelige details prijs te geven.
Veelgestelde vragen
Is HTTPS genoeg om een API te beveiligen?
Nee, HTTPS beschermt het verkeer onderweg, maar bepaalt niet wie toegang heeft tot de API. Het versleutelt de verbinding en helpt voorkomen dat derden verzoeken onderweg uitlezen of wijzigen. Een API heeft daarnaast controles nodig om de identiteit van de aanroeper te beoordelen en te bepalen welke bewerkingen zijn toegestaan. Beperk ook de hoeveelheid gegevens die een antwoord bevat en stel waar nodig limieten in voor verzoeken. HTTPS is dus een noodzakelijke beveiligingslaag, geen vervanging voor API-authenticatie of autorisatie.
Wat is het verschil tussen JWT- en opaque access tokens?
Een JWT bevat claims die een API lokaal kan controleren, terwijl een opaque token zelf geen leesbare informatie over de gebruiker of rechten prijsgeeft. Bij een JWT controleert de API onder meer de handtekening, vervaltijd en ontvanger; de tokeninhoud alleen vertrouwen is niet genoeg. Een opaque token moet meestal bij de autorisatieserver worden gecontroleerd, bijvoorbeeld via introspectie. JWT’s kunnen controles sneller maken, maar zijn na uitgifte lastiger direct in te trekken. Opaque tokens bieden meer centrale controle, maar vereisen doorgaans een netwerkcontrole.
Hoe voorkom je replayaanvallen op een API?
Voorkom replayaanvallen door verzoeken zo in te richten dat een onderschept verzoek niet onbeperkt opnieuw bruikbaar is. Gebruik HTTPS en laat gevoelige verzoeken een beperkte geldigheidsduur hebben. Afhankelijk van het protocol kunnen een unieke nonce, een tijdstempel of een handtekening over de verzoekinhoud helpen om hergebruik te herkennen. Bewaar gebruikte identificatoren kort genoeg om dubbele verzoeken af te wijzen. Voor betaal- of wijzigingsverzoeken zijn idempotentiesleutels ook nuttig: die voorkomen dat een herhaling dezelfde handeling meerdere keren uitvoert.
Hoe test je API-authenticatie veilig zonder productiedata?
Test API-authenticatie in een aparte testomgeving met testaccounts, fictieve gegevens en credentials die niet in productie geldig zijn. Zo kun je zowel succesvolle verzoeken als afwijzingen controleren zonder echte gebruikersgegevens of systemen te raken. Test bijvoorbeeld ontbrekende, ongeldige en verlopen tokens en verzoeken met onvoldoende rechten. Sla testgeheimen op dezelfde beheerste manier op als productiegeheimen en voorkom dat ze in testlogs verschijnen. Controleer ook dat de testomgeving geen onverwachte toegang heeft tot productiebronnen.
Moet elke microservice een token controleren als er al een API-gateway is?
Ja, gevoelige microservices moeten zelf controleren of een verzoek voor hun functie en gegevens is toegestaan, ook wanneer er een API-gateway voor staat. Een gateway kan centrale controles uitvoeren, zoals het weigeren van verzoeken zonder geldig token, maar verkeer kan soms buiten die route om de service bereiken. Controleer daarom netwerktoegang en valideer in de service de relevante identiteit en rechten. Vertrouw niet alleen op headers die een gateway toevoegt, tenzij die headers niet door onbevoegde aanroepers kunnen worden vervalst.
