Persoonlijke toegangstokens, machine-tot-machine authenticatie en API-sleutels definitie en hun real-world scenario's

Als je een software of SaaS-product bouwt, zul je vaak een brede use-case of functieaanvraag tegenkomen: API-aanvragen. Vooral grotere enterprise-klanten willen soms programmatische toegang tot middelen, op persoonlijk of organisatorisch niveau.

In deze gevallen zijn API-sleutels, Persoonlijke Toegangstokens (PATs) en Machine-tot-machine (M2M) authenticatie vaak nodig. In dit artikel verkennen we de verschillen tussen deze methoden en hoe ze kunnen worden gebruikt in B2B productontwikkeling voor ontwikkelaars.

De overeenkomsten#

Laten we eerst kijken naar de overeenkomsten tussen deze drie.

1. Beveiligingsdoel: Alle drie methoden worden gebruikt om toegang tot APIs, diensten of bronnen te beveiligen en te controleren. Ze dienen allemaal als middel voor authenticatie en/of autorisatie.
2. Op token gebaseerde aanpak: Elke methode omvat doorgaans het gebruik van een unieke string of token voor identificatie. Deze tokens worden meestal verzonden met API-aanvragen, vaak in headers of als queryparameters.
3. Herroepbaar: Tokens of sleutels in alle drie methoden kunnen worden ingetrokken of ongeldig gemaakt als ze gecompromitteerd zijn of niet langer nodig zijn. Dit maakt snelle beveiligingsreacties mogelijk zonder het onderliggende systeem te veranderen.
4. Programmeerbare toegang: Alle drie methoden faciliteren programmatische toegang tot APIs of diensten. Ze geven automatisering en integratie tussen verschillende systemen of applicaties mogelijk.
5. Auditable: Het gebruik van deze authenticatiemethoden kan worden geregistreerd en gecontroleerd. Dit stelt je in staat om API-toegang te volgen, verdachte activiteiten te monitoren en compliance rapportage uit te voeren.
6. Aanpasbaar aan toegangscontrole: Alle drie methoden kunnen worden geïmplementeerd met verschillende niveaus van toegangscontrole en machtigingen. Ze kunnen worden aangepast aan verschillende beveiligingsmodellen en architectonische vereisten.
7. Protocolonafhankelijk: Hoewel ze vaak worden gebruikt met REST APIs, kunnen deze methoden worden toegepast op verschillende typen APIs en protocollen.

Door deze overeenkomsten te begrijpen, kun je de gemeenschappelijke fundamenten van deze authenticatiemethoden herkennen. Hun verschillen maken het mogelijk om de meest geschikte oplossing te kiezen voor specifieke use-cases en beveiligingsvereisten.

Laten we nu hun verschillen bespreken, met de nadruk op hun use-cases en wanneer je elke methode moet gebruiken.

De verschillen#

API-sleutels#

API-sleutels worden gebruikt om de opgeroepen applicatie of dienst te identificeren en te autoriseren. Ze zijn doorgaans langdurig en statisch totdat ze worden gewijzigd en hebben vaak een vastgestelde set machtigingen. Ze worden voornamelijk gebruikt voor server-naar-server communicaties of toegang tot openbare data, deze tokens vertegenwoordigen meestal geen specifieke gebruiker.

Hoe werken API-sleutels?#

Een API-sleutel wordt uitgegeven door een API-provider en gegeven aan een geregistreerde API-consument [1], die het bij elke aanvraag toevoegt. De API-server controleert vervolgens de API-sleutel om de identiteit van de consument te valideren voordat de gevraagde data wordt teruggestuurd.

API-sleutels zijn niet zo effectief als andere vormen van API-authenticatie, zoals OAuth en JWT, maar ze spelen nog steeds een belangrijke rol in het helpen van API-producenten om gebruik te monitoren terwijl gevoelige data beveiligd blijft.

[1]: Een API-consument is elke applicatie, dienst, of gebruiker die interactie heeft met een API om toegang te krijgen tot zijn functionaliteit of data. Ze sturen aanvragen naar de API om operaties uit te voeren, zoals het ophalen, creëren, bijwerken of verwijderen van bronnen. API-consumenten kunnen webapplicaties, mobiele apps, andere servers, of zelfs individuele ontwikkelaars zijn die de API gebruiken om te integreren met andere diensten of om nieuwe functionaliteiten te bouwen op bestaande platforms.

Postman: Wat is een API-sleutel?

Gebruikssituaties#

Bij het bespreken van API-sleutel gebruikssituaties, vermelden mensen vaak automatisering, gegevensdeling, testen, ontwikkeling en beveiligingscontrole. Echter, deze zijn vrij technisch. In real-world scenario's is het meest voorkomende doel bij het bouwen van producten integratie.

Voorbeeld 1: Integratie met Zapier#

Zapier: Voeg authenticatie toe met API-sleutel

Zapier is een populair automatiseringstool dat verschillende webapplicaties verbindt. Bij het integreren van een applicatie met Zapier, worden API-sleutels gebruikt om toegang tot de API van de applicatie te authenticeren en te autoriseren. Bijvoorbeeld, als je taken wilt automatiseren tussen een CRM-systeem en een e-mailmarketingtool, genereer je een API-sleutel van het CRM-systeem en verstrek je die aan Zapier. Deze sleutel wordt vervolgens gebruikt om aanvragen van Zapier naar de CRM's API te authenticeren, waardoor de gegevens veilig tussen de twee systemen kunnen stromen.

Voorbeeld 2: Integratie met Stripe#

Stripe maakt gebruik van API-sleutels voor veilige integratie met verschillende platforms en applicaties. Gebruik het Developers Dashboard om API-sleutels te creëren, onthullen, verwijderen en te rollen.

Persoonlijke Toegangstokens (PATs)#

Een persoonlijk toegangstoken is een ander vergelijkbaar concept maar vertegenwoordigt de identiteit en machtigingen van een specifieke gebruiker, wordt dynamisch gegenereerd na succesvolle authenticatie of inloggen, en heeft typisch een beperkte levensduur maar kan worden vernieuwd. Ze bieden fijne-grained toegangscontrole naar gebruikersspecifieke gegevens en mogelijkheden en worden vaak gebruikt voor CLI-tools, scripts of persoonlijke API-toegang.

Hoe werken PATs#

1. Creatie en beheer: Gebruikers genereren PATs via hun accountinstellingen in het betreffende platform.
   • Bijvoorbeeld, in GitHub kunnen gebruikers fijne-grained of klassieke PATs creëren met specifieke machtigingen en vervaldatums.
   • In Atlassian-producten zoals Jira en Confluence kunnen gebruikers PATs creëren vanuit hun profielinstellingen, met specificatie van de naam van het token en optionele vervaldatum.
2. Gebruik: PATs worden gebruikt als toegangs- tokens in de Authorization-header van API-aanvragen. Dit betekent dat ze in de HTTP-headers worden opgenomen om de aanvraag te authenticeren.
   • Ze maken veilige toegang tot API-bronnen mogelijk, waardoor gebruikers acties zoals creëren, lezen, bijwerken en verwijderen van bronnen kunnen uitvoeren op basis van de aan het token verleende machtigingen.
   • PATs kunnen worden gebruikt over meerdere applicaties binnen een platform, wat een uniforme manier biedt om toegang en machtigingen te beheren.
3. Herroep en stel vervaldatum in:
   • PATs bieden verbeterde beveiliging door gebruikers in staat te stellen tokens in te trekken als ze gecompromitteerd zijn, zonder het accountwachtwoord te hoeven veranderen.
   • Platforms raden vaak aan om vervaldatums voor PATs in te stellen om het risico van langdurige tokens die worden misbruikt te verminderen.

Gebruikssituaties#

Er zijn twee typische scenario's,

Automatisering en scripting

Dit betekent dat wanneer een ontwikkelaar een PAT gebruikt om de implementatie van code vanuit een repository naar een productomgeving te automatiseren, waardoor handmatige tussenkomst wordt verminderd en consistentie wordt verzekerd.

Bijvoorbeeld, GitHub-gebruikers kunnen PATs creëren om Git-operaties over HTTPS te authenticeren en te communiceren met GitHub's REST API. Dit is nuttig voor ontwikkelaars die taken zoals het klonen van repositories, pushen van commits, of beheren van issues en pull-aanvragen moeten automatiseren.

Integratie met externe applicaties

Dit betekent het mogelijk maken van veilige communicatie tussen verschillende systemen en applicaties. Dit lijkt op het scenario waarbij API-sleutel integratie betrokken is, maar PAT vertegenwoordigt de gebruiker, niet de client of applicatie.

Bijvoorbeeld, een projectmanager gebruikt een PAT om een projectmanagementtool te integreren met een extern probleemvolgsysteem, waardoor naadloze gegevenswissel en synchronisatie mogelijk is, zoals Atlassian (Jira en Confluence).

De bovenstaande scenario's lijken meer op ontwikkelaarstools. Zijn PATs alleen nuttig voor dit soort producten? Nee. Hier zijn twee extra voorbeelden: een is een CMS-systeem en een is een productiviteitstool.

Voorbeeld 1: Contentful#

Contentful: Persoonlijke Toegangstokens

Contentful is een headless CMS-platform, biedt PATs als een alternatief voor OAuth-tokens voor toegang tot hun Content Management API (CMA).

Belangrijke kenmerken zijn onder andere:

• Gebruikers kunnen meerdere tokens creëren met verschillende scopen en machtigingen.
• Tokens zijn gekoppeld aan het account van de gebruiker, waarbij ze hun machtigingen erven.
• PATs zijn bijzonder nuttig voor ontwikkelings- en automatiseringsdoeleinden.

Voorbeeld 2: Airtable#

Airtable Ondersteuning: Persoonlijke Toegangstokens Creëren

Airtable - een samenwerkingstool in de cloud, implementeert PATs voor API-toegang.

Hun systeem maakt mogelijk:

• Het creëren van meerdere tokens met verschillende scopen en toegangslevels.
• Tokens kunnen worden beperkt tot specifieke bases of werkruimtes.
• Enterprise admins kunnen tokens creëren met bredere toegang binnen de organisatie.

Machine-tot-machine (M2M) authenticatie#

M2M is ontworpen voor service-naar-service communicatie zonder menselijke tussenkomst. Het komt voort uit het idee dat gebruikersnamen en wachtwoorden onvoldoende zijn voor het beschermen van diensten en niet efficiënt zijn voor effectieve automatisering.

Machine-tot-machine (M2M) toepassingen passen nu de Client Credentials Flow toe, welke is gedefinieerd in het OAuth 2.0 RFC 6749 autorisatieprotocol. Het kan ook vergelijkbare standaardprotocollen ondersteunen. Ja, M2M-authenticatie is strikter in vergelijking met PATs en API-sleutels als het gaat om het open-standaard zijn.

Het authenticeert de applicatie zelf of de dienst zelf, niet een gebruiker, en implementeert vaak JWT (JSON webtokens) voor stateless authenticatie. Dit biedt een veilige manier voor diensten om met elkaar te communiceren in gedistribueerde systemen.

Hoe werkt authenticatie van machine-tot-machine#

Het volgt een vergelijkbaar proces:

1. Client credentials: Elke machine (of dienst) heeft een unieke client-ID en secret.
2. Token aanvraag: De dienst stuurt deze credentials naar de autorisatieserver.
3. Toegangstoken: Na validatie geeft de autorisatieserver een toegangstoken uit, vaak een JWT (JSON Web Token).
4. API-aanvragen: De dienst gebruikt dit token om API-aanvragen naar een andere dienst te authenticeren en te autoriseren.
5. Validatie: De ontvangende dienst valideert het token voordat het toegang verleent tot zijn middelen.

Gebruikssituaties#

Hier is een beknopt voorbeeld van het gebruik van machine-tot-machine (M2M) authenticatie voor backend-naar-backend communicatie:

Scenario: Dienst A moet toegang krijgen tot gegevens van Dienst B's API.

1. Setup:

   • Dienst A is geregistreerd als een client bij een autorisatieserver.
   • Dienst A krijgt een client-ID en client secret.

2. Authenticatie:

   • Dienst A vraagt een toegangstoken aan bij de autorisatieserver:

3. Token uitgifte:

   • De autorisatieserver verifieert de credentials en geeft een JWT toegangstoken uit.

4. API-aanvraag:

   • Dienst A gebruikt het token om data van Dienst B aan te vragen:

5. Validatie:

   • Dienst B valideert het token bij de autorisatieserver.

6. Reactie:

   • Als het geldig is, retourneert Dienst B de gevraagde gegevens aan Dienst A.

Dit proces maakt veilige, geautomatiseerde communicatie tussen Dienst A en Dienst B mogelijk zonder gebruikersinterventie, gebruikmakend van de OAuth 2.0 client credentials flow.

Apparaat-naar-apparaat communicatie

Apparaat-naar-apparaat communicatie, met name in de context van IoT (Internet of Things), is sterk afhankelijk van machine-tot-machine (M2M) authenticatie om veilige en efficiënte gegevensuitwisseling te waarborgen.

Bijvoorbeeld, zoals slimme thuisapparaten, communiceert een slimme thermostaat met een centraal thuisautomatiseringscentrum om temperatuuraanpassingen door te voeren op basis van gebruikersvoorkeuren. De thermostaat gebruikt M2M authenticatie om veilig gegevens naar het centrum te sturen en commando's te ontvangen, waarbij ervoor wordt gezorgd dat alleen geautoriseerde apparaten interactie kunnen hebben met het verwarmingssysteem van het huis.

Belangrijk overzicht#

Ok, je hebt het eind van dit artikel bereikt. Kan ik een snelle samenvatting krijgen? Zeker! Hier zijn de belangrijkste punten:

1. Schaal: API-sleutels zijn breed, PATs (Persoonlijke Toegangstokens) zijn gebruiker-specifiek, en M2M (Machine-tot-machine) tokens zijn dienst-specifiek.
2. Levensduur: API-sleutels zijn langdurig, PATs hebben een kortere levensduur, en M2M tokens kunnen variëren.
3. Representatie: API-sleutels zijn ondoorzichtige strings, PATs kunnen ondoorzichtig of gestructureerd zijn, en M2M tokens gebruiken vaak JWTs.
4. Gebruikssituatie: API-sleutels zijn voor eenvoudige API-toegang, PATs zijn voor gebruikersgerichte operaties, en M2M tokens zijn voor service-tot-service communicatie.