Personliga Åtkomsttoken, Maskin-till-Maskin-autentisering och API-nycklar definition och deras verkliga scenarier

Om du bygger en mjukvara eller SaaS-produkt kommer du ofta att stöta på ett brett användningsfall eller funktionsförfrågan: API-förfrågningar. Särskilt större företagskunder kan vilja ha programmatisk åtkomst till resurser, antingen på en personlig eller organisatorisk nivå.

I dessa fall är API-nycklar, Personliga Åtkomsttoken (PAT) och Maskin-till-Maskin (M2M)-autentisering ofta nödvändiga. I den här artikeln kommer vi att utforska skillnaderna mellan dessa metoder och hur de kan användas i B2B-produktutveckling för utvecklare.

Likheterna#

Låt oss först titta på likheterna mellan dessa tre.

1. Säkerhetsändamål: Alla tre metoder används för att säkra och kontrollera åtkomst till API:er, tjänster eller resurser. De tjänar alla som ett medel för autentisering och/eller auktorisering.
2. Token-baserad metod: Varje metod involverar vanligtvis användningen av en unik sträng eller token för identifiering. Dessa token skickas vanligtvis med API-förfrågningar, ofta i headers eller som frågeparametrar.
3. Återkallelig: Token eller nycklar i alla tre metoder kan återkallas eller ogiltigförklaras om de komprometteras eller inte längre behövs. Detta möjliggör snabba säkerhetsåtgärder utan att ändra det underliggande systemet.
4. Programmatisk åtkomst: Alla tre metoder underlättar programmatisk åtkomst till API:er eller tjänster. De möjliggör automatisering och integration mellan olika system eller applikationer.
5. Auditabla: Användning av dessa autentiseringsmetoder kan loggas och granskas. Detta gör det möjligt att spåra API-åtkomst, övervaka misstänkta aktiviteter och följa upp överensstämmelse.
6. Anpassningsbart efter åtkomstkontroll: Alla tre metoder kan implementeras med olika nivåer av åtkomstkontroll och behörigheter. De kan anpassas till olika säkerhetsmodeller och arkitekturkrav.
7. Protokolloberoende: Även om de ofta används med REST API:er, kan dessa metoder tillämpas på olika typer av API:er och protokoll.

Att förstå dessa likheter hjälper till att känna igen de gemensamma grunderna för dessa autentiseringsmetoder. Deras skillnader gör det möjligt för dig att välja den mest lämpliga lösningen för specifika användningsfall och säkerhetskrav.

Låt oss nu diskutera deras skillnader, med fokus på deras användningsfall och när man ska använda varje metod.

Skillnaderna#

API-nycklar#

API-nycklar används för att identifiera och auktorisera den anropande applikationen eller tjänsten. De är vanligtvis långlivade och statiska tills de roteras och har ofta en fast uppsättning behörigheter. De används främst för server-till-server-kommunikation eller åtkomst till offentlig data, dessa token representerar vanligtvis inte en specifik användare.

Hur fungerar API-nycklar?#

En API-nyckel utfärdas av en API-leverantör och ges till en registrerad API-konsument [1], som inkluderar den vid varje begäran. API-servern kontrollerar sedan API-nyckeln för att verifiera konsumentens identitet innan de returnerar de begärda uppgifterna.

API-nycklar är inte lika effektiva som andra former av API-autentisering, såsom OAuth och JWT, men de spelar fortfarande en viktig roll i att hjälpa API-producenter att övervaka användning samtidigt som känslig data hålls säker.

[1]: En API-konsument är vilken applikation, tjänst eller användare som helst som interagerar med ett API för att få tillgång till dess funktionalitet eller data. De skickar förfrågningar till API:et för att utföra operationer som att hämta, skapa, uppdatera eller radera resurser. API-konsumenter kan vara webbapplikationer, mobilappar, andra servrar eller till och med individuella utvecklare som använder API:et för att integrera med andra tjänster eller för att bygga nya funktioner ovanpå befintliga plattformar.

Postman: Vad är en API-nyckel?

Användningsfall#

När folk diskuterar användningsfall för API-nycklar, nämner de ofta automatisering, datadelning, testning, utveckling och säkerhetskontroll. Dessa är dock ganska tekniska. I verkliga scenarier är det vanligaste syftet vid produktutveckling integration.

Exempel 1: Integration med Zapier#

Zapier: Lägg till autentisering med API-nyckel

Zapier är ett populärt automatiseringsverktyg som kopplar ihop olika webbapplikationer. När du integrerar en applikation med Zapier används API-nycklar för att autentisera och auktorisera åtkomst till applikationens API. Till exempel, om du vill automatisera uppgifter mellan ett CRM-system och ett e-postmarknadsföringsverktyg, skulle du generera en API-nyckel från CRM-systemet och förse Zapier med den. Denna nyckel används sedan för att autentisera förfrågningar från Zapier till CRM:ets API, vilket gör att data kan flöda säkert mellan de två systemen.

Exempel 2: Integration med Stripe#

Stripe utnyttjar API-nycklar för säker integration med olika plattformar och applikationer. Använd Utvecklarinstrumentpanelen för att skapa, visa, ta bort och rotera API-nycklar.

Personliga Åtkomsttoken (PAT)#

En personlig åtkomsttoken är ett annat liknande koncept men representerar en specifik användares identitet och behörigheter, genereras dynamiskt vid lyckad autentisering eller inloggning, och har vanligtvis en begränsad livslängd men kan förnyas. De ger fininställd åtkomstkontroll till användarspecifik data och funktioner och används ofta för CLI-verktyg, skript eller personlig API-åtkomst.

Hur fungerar PAT#

1. Skapande och hantering: Användare genererar PAT via sina kontoinställningar på respektive plattform.
   • Till exempel kan GitHub-användare skapa fininställda eller klassiska PAT med specifika behörigheter och utgångsdatum.
   • I Atlassians produkter som Jira och Confluence kan användare skapa PAT från sina profilinställningar, specificera tokenens namn och valfri utgång.
2. Användning: PAT används som bärare-token i Authorizationsheaders i API-begäran. Detta innebär att de inkluderas i HTTP-header för att autentisera begäran.
   • De möjliggör säker åtkomst till API-resurser, vilket tillåter användare att utföra åtgärder som skapande, läsning, uppdatering och radering av resurser baserat på de behörigheter som token ger.
   • PAT kan användas i flera applikationer inom en plattform, vilket ger ett enhetligt sätt att hantera åtkomst och behörigheter.
3. Återkalla och ställa in utgång:
   • PAT ger ökad säkerhet genom att tillåta användare att återkalla token om de komprometteras, utan att behöva ändra kontolösenordet.
   • Plattformar rekommenderar ofta att ställa in utgångsdatum för PAT för att minska risken för långlivade token som utnyttjas.

Användningsfall#

Det finns två typiska scenarier,

Automatisering och skriptning

Detta innebär när en utvecklare använder en PAT för att automatisera implementeringen av kod från ett förvar till en produktionsmiljö, minska manuell intervention och säkerställa konsistens.

Till exempel kan GitHub-användare skapa PAT för att autentisera Git-operationer över HTTPS och interagera med GitHubs REST API. Detta är användbart för utvecklare som behöver automatisera uppgifter som kloning av förvar, skjuta åtaganden eller hantera problem och begäran om pull.

Integration med externa applikationer

Detta innebär, möjligtgöra säker kommunikation mellan olika system och applikationer. Detta ser ut som ett liknande scenario med API-nyckelintegration, men PAT representerar användaren, inte klienten eller applikationen.

Till exempel, en projektledare använder en PAT för att integrera ett projektledningsverktyg med ett externt problemspårningssystem, vilket möjliggör sömlöst datautbyte och synkronisering, som Atlassian (Jira och Confluence).

Ovanstående scenarion är mer som utvecklingsverktyg. Är PAT bara användbara för denna typ av produkter? Nej. Här är två ytterligare exempel: en är ett CMS-system, och en är ett produktivitetsverktyg.

Exempel 1: Contentful#

Contentful: Personliga Åtkomsttoken

Contentful är en headless CMS-plattform som erbjuder PAT som ett alternativ till OAuth-token för att få åtkomst till deras Content Management API (CMA).

Nyckelfunktioner inkluderar:

• Användare kan skapa flera token med olika räckvidder och behörigheter.
• Token är kopplade till användarens konto och ärver deras behörigheter.
• PAT är särskilt användbara för utvecklings- och automationsändamål.

Exempel 2: Airtable#

Skapa Personliga Åtkomsttoken | Airtable Support

Airtable – en molnsamarbetsplattform, implementerar PAT för API-åtkomst.

Deras system tillåter:

• Skapandet av flera token med olika räckvidder och åtkomstnivåer.
• Token kan begränsas till specifika baser eller arbetsytor.
• Företagsadministratörer kan skapa token med bredare åtkomst över organisationen.

Maskin-till-Maskin (M2M)-autentisering#

M2M är utformad för tjänst-till-tjänst-kommunikation utan mänsklig intervention. Det härrör från idén att användarnamn och lösenord är otillräckliga för att skydda tjänster och inte är effektiva för effektiv automatisering.

Maskin-till-maskin (M2M)-applikationer adopterar nu klientens autentiseringsflöde, som definieras i OAuth 2.0 RFC 6749-autorisationsprotokoll. Det kan också stödja liknande standardprotokoll. Ja, M2M-autentisering är mer strikt till öppna standarder jämfört med PAT och API-nycklar.

Det autentiserar själva applikationen eller tjänsten, inte en användare, och implementerar ofta JWT (JSON Web Tokens) för statslös autentisering. Detta ger ett säkert sätt för tjänster att interagera med varandra i distribuerade system.

Hur maskin-till-maskin-autentisering fungerar#

Det följer en liknande process:

1. Klientuppgifter: Varje maskin (eller tjänst) har en unik klient-ID och hemlighet.
2. Tokenbegäran: Tjänsten skickar dessa uppgifter till autentiseringsservern.
3. Access token: Vid validering utfärdar autentiseringsservern en access token, ofta en JWT (JSON Web Token).
4. API-förfrågningar: Tjänsten använder denna token för att autentisera och auktorisera API-förfrågningar till en annan tjänst.
5. Validering: Den mottagande tjänsten validerar token innan de beviljar åtkomst till sina resurser.

Användningsfall#

Här är ett kortfattat exempel på att använda maskin-till-maskin (M2M) autentisering för backend-till-backend-kommunikation:

Scenario: Tjänst A behöver komma åt data från Tjänst B:s API.

1. Installation:

   • Tjänst A är registrerad som en klient hos en autentiseringsserver.
   • Tjänst A får ett klient-ID och en klienthemlighet.

2. Autentisering:

   • Tjänst A begär en access token från autentiseringsservern:

3. Tokenutfärdande:

   • Autentiseringsservern verifierar uppgifterna och utfärdar en JWT access token.

4. API-förfrågan:

   • Tjänst A använder token för att begära data från Tjänst B:

5. Validering:

   • Tjänst B validerar token hos autentiseringsservern.

6. Svar:

   • Om giltig returnerar Tjänst B de begärda uppgifterna till Tjänst A.

Denna process möjliggör säker, automatiserad kommunikation mellan Tjänst A och Tjänst B utan användarintervention, med användningen av OAuth 2.0 klientens autentiseringsflöde.

Enhet-till-enhet-kommunikation

Enhet-till-enhet-kommunikation, särskilt i samband med IoT (Internet of Things), förlitar sig starkt på maskin-till-maskin (M2M) autentisering för att säkerställa säker och effektiv datautbyte.

Till exempel, som smarta hem-enheter, kommunicerar en smart termostat med en central hemautomationshub för att justera temperaturinställningarna baserat på användarens preferenser. Termostaten använder M2M-autentisering för att säkert skicka data till hubben och ta emot kommandon, vilket säkerställer att endast auktoriserade enheter kan interagera med hemmets värmesystem.

Nyckelsammanfattning#

Ok, du har nått slutet av denna artikel. Kan jag få en snabb sammanfattning? Självklart! Här är en titt på nyckelpunkterna:

1. Omfattning: API-nycklar är breda, PAT (Personliga Åtkomsttoken) är användarspecifika, och M2M (Maskin-till-Maskin) tokener är tjänstespecifika.
2. Livslängd: API-nycklar är långlivade, PAT har en kortare livslängd och M2M tokener kan variera.
3. Representation: API-nycklar är opaka strängar, PAT kan vara opaka eller strukturerade, och M2M tokener använder ofta JWT.
4. Användningsfall: API-nycklar är för enkel API-åtkomst, PAT är för användarcentrerade operationer, och M2M tokener är för tjänst-till-tjänst-kommunikation.