Programmeerbare authenticatie: API-sleutel, persoonlijke toegangstoken en OAuth client credentials flow

Achtergrond#

In softwareontwikkeling, wanneer we programmeermatig toegang moeten krijgen tot API-bronnen via CLI-opdrachten, of communicatie moeten tot stand brengen tussen backend-services, zijn er meestal drie authenticatiemechanismen die veel door ons ontwikkelaars worden gebruikt: API-sleutel, Personal Access Token (PAT) en OAuth client credentials flow (in Logto genaamd Machine-to-Machine). Maar wat zijn de verschillen ertussen? Wat is het meest geschikte scenario voor elk van deze methoden? In deze blogpost zullen we ingaan op de overeenkomsten, verschillen en inzicht geven in wanneer elk te gebruiken in verschillende scenario's.

Definities#

• API-sleutel: Een eenvoudige tekenreeks die je verzoek bij een API-bron kan authenticeren.
• Persoonlijke toegangstoken (PAT): Ook een eenvoudige tekenreeks, maar vertegenwoordigt een gebruiker wanneer deze wordt gebruikt om bij een API-bron te authenticeren. Het is een delegatie van een gebruiker.
• Logto Machine-to-Machine (Logto M2M): Een standaard OAuth client credential flow, die vereist dat een client vooraf geregistreerd is, en vereist het gebruik van de client-ID en geheime sleutel om een toegangstoken te verkrijgen. Dus, Logto M2M-referenties vertegenwoordigen een vertrouwde client en de aard van OAuth client credentials flow maakt het relatief ingewikkeld in gebruik.

Overeenkomsten#

1. Authenticatiedoel#

• Alle drie, API-sleutel, PAT en Logto M2M, dienen het primaire doel om een gebruiker of een applicatie te authenticeren om toegang te krijgen tot een specifieke service of bron. Ze fungeren als referenties om de identiteit van de aanvrager te bewijzen en worden meestal gebruikt in CLI-opdrachten of backend-naar-backend communicatiescenario's.

2. Beveiligingsmaatregelen#

• Alle drie deze authenticatiemethoden moeten met beveiliging in gedachten worden behandeld. Ontwikkelaars moeten zorgen voor veilige opslag en transmissie om ongeautoriseerde toegang te voorkomen.

Verschillen#

1. Gebruikerscontext#

• API-sleutel identificeert geen hoofdgebruiker en biedt ook geen autorisatieinformatie. Daarom worden API-sleutels vaak gebruikt voor anonieme toegang tot openbare data of bronnen. Niet alle services worden ondersteund door het gebruik van API-sleutels.
• PAT is gebruikersidentiteiten en zal je vertegenwoordigen wanneer het wordt gebruikt om een API-bron aan te vragen. In sommige systemen is het met PAT's niet toegestaan om toegang te krijgen tot bepaalde services. Bijvoorbeeld het publiceren van NuGet-pakketten naar de Azure Artifacts-feed.
• Logto M2M-referenties kunnen alleen worden gebruikt door vertrouwde clients. De client moet vooraf geregistreerd zijn om geauthenticeerd te worden. Bij het gebruik van Logto M2M-referenties vertegenwoordigt het de vertrouwde client in plaats van de gebruiker die het gebruikt.

2. Granulariteit van machtigingen#

• PAT en Logto M2M-referenties bieden meestal meer gedetailleerde controle over machtigingen vergeleken met de API-sleutel, waardoor fijne controle mogelijk is over welke acties kunnen worden uitgevoerd.

3. Tokenformaat#

• API-sleutel en PAT zijn meestal ondoorzichtige tekenreeksen, eenvoudig en makkelijk.
• Toegangstokens die worden uitgegeven via het Logto M2M-mechanisme zijn meestal in JWT-formaat.

4. Autorisatiestroom#

• API-sleutel en PAT zijn door het systeem gegenereerde ondoorzichtige tekenreeksen, er zijn geen authenticatiestromen bij het proces betrokken. Bijvoorbeeld, je kunt de Google Cloud Natural Language API op deze manier aanroepen:

• Logto M2M maakt gebruik van de standaard OAuth 2.0 client credential flow. Elke client moet een paar client-ID en client-geheim verkrijgen vooraf, waarmee de client later een toegangstoken kan verkrijgen. De client gebruikt vervolgens het toegangstoken om toegang te krijgen tot de API-bron.

Wanneer te gebruiken#

API-sleutel#

• Service-tot-service communicatie: API-sleutels zijn geschikt voor scenario's waarin applicaties direct via CLIs met API's moeten communiceren. Bijvoorbeeld het aanroepen van OpenAI API's.
• Openbare API's: Bij het openbaar maken van API's bieden API-sleutels een eenvoudige methode van toegangscontrole.
• Vereenvoudigde configuratie: Voor snelle en eenvoudige authenticatiebehoeften, vooral in de ontwikkelingsfase. In tegenstelling tot Logto M2M, vereisen API-sleutels geen voorafgaande registratie van de client en hoeft er ook niet om een toegangstoken te worden gevraagd. Je voegt simpelweg je API-sleutel als parameter toe aan je verzoek en het werkt gewoon.

Persoonlijke toegangstoken (PAT)#

• Gebruikersspecifieke acties: Wanneer een applicatie acties namens een gebruiker moet uitvoeren.
• Fijnmazige toegangscontrole (gebruiker): Wanneer nauwkeurige controle over de acties die een gebruiker kan uitvoeren vereist is.

Logto Machine-to-Machine (Logto M2M)#

• Beveiliging: Logto M2M is ideaal voor scenario's waarin alleen vertrouwde clients toegang mogen krijgen tot de backend-services.
• Fijnmazige toegangscontrole (client): Wanneer nauwkeurige controle over de acties die een applicatie kan uitvoeren vereist is.

Conclusie#

Samenvattend, de keuze tussen API-sleutels, PAT's en Logto M2M hangt af van de specifieke vereisten van je applicatie, of het nu gaat om gebruikersspecifieke acties, machine-tot-machine communicatie, of een combinatie van beide. Beoordeel de beveiliging en functionele behoeften om te bepalen welke authenticatiemethode het meest geschikt is voor jouw gebruikssituatie.

Het Logto M2M-mechanisme stelt gebruikers in staat om gedetailleerde toegangscontroles in te stellen over RBAC (Role-based Access Control) functie. We zijn ook van plan om API-sleutel en PAT in de nabije toekomst te ondersteunen. Blijf op de hoogte van onze functie-updates!