Osobiste tokeny dostępu, uwierzytelnianie maszyna-do-maszyny oraz definicja kluczy API i ich scenariusze w rzeczywistym świecie

Jeśli tworzysz oprogramowanie lub produkt SaaS, często napotkasz szeroki przypadek użycia lub prośbę o funkcję: Żądania API. Szczególnie więksi klienci korporacyjni mogą chcieć mieć programatyczny dostęp do zasobów, zarówno na poziomie osobistym, jak i organizacyjnym.

W takich przypadkach często potrzebne są klucze API, osobiste tokeny dostępu (PAT) i uwierzytelnianie maszyna-do-maszyny (M2M). W tym artykule przyjrzymy się różnicom między tymi metodami i temu, jak mogą być używane w rozwoju produktów B2B przez programistów.

Podobieństwa#

Najpierw przyjrzyjmy się podobieństwom między tymi trzema.

1. Cel bezpieczeństwa: Wszystkie trzy metody są używane do zabezpieczania i kontrolowania dostępu do API, usług lub zasobów. Wszystkie pełnią funkcję uwierzytelniania i/lub autoryzacji.
2. Podejście oparte na tokenach: Każda z tych metod zazwyczaj wiąże się z użyciem unikalnego ciągu lub tokena do identyfikacji. Te tokeny są zazwyczaj przesyłane wraz z żądaniami API, często w nagłówkach lub jako parametry zapytania.
3. Możliwość cofnięcia: Tokeny lub klucze w każdej z tych trzech metod mogą zostać cofnięte lub unieważnione, jeśli zostaną skompromitowane lub nie są już potrzebne. Pozwala to na szybką reakcję na zagrożenia bez potrzeby zmiany podstawowego systemu.
4. Dostęp programowy: Wszystkie trzy metody ułatwiają programatyczny dostęp do API lub usług. Umożliwiają automatyzację i integrację między różnymi systemami lub aplikacjami.
5. Możliwość audytu: Użycie tych metod uwierzytelniania może być logowane i podlegać audytowi. Umożliwia to śledzenie dostępu do API, monitorowanie podejrzanych działań i raportowanie zgodności.
6. Możliwość dostosowania do kontroli dostępu: Wszystkie trzy metody mogą być zaimplementowane z różnymi poziomami kontroli dostępu i uprawnień. Mogą być dostosowane do różnych modeli bezpieczeństwa i wymagań architektonicznych.
7. Niezależność od protokołu: Chociaż są często stosowane z REST API, te metody mogą być zastosowane do różnych rodzajów API i protokołów.

Zrozumienie tych podobieństw pomaga rozpoznać wspólne fundamenty tych metod uwierzytelniania. Różnice między nimi pozwalają wybrać najbardziej odpowiednie rozwiązanie dla specyficznych przypadków użycia i wymagań bezpieczeństwa.

Teraz omówmy ich różnice, skupiając się na przypadkach użycia i na tym, kiedy każda metoda jest najlepsza.

Różnice#

Klucze API#

Klucze API są używane do identyfikacji i autoryzacji aplikacji lub usługi, która wykonuje żądanie. Zazwyczaj są długowieczne i statyczne, dopóki nie zostaną obrócone i często mają stały zestaw uprawnień. Są one głównie używane do komunikacji serwer-serwer lub uzyskiwania dostępu do publicznych danych; te tokeny zazwyczaj nie reprezentują konkretnego użytkownika.

Jak działają klucze API?#

Klucz API jest wydawany przez dostawcę API i przekazywany zarejestrowanemu konsumentowi API [1], który dołącza go do każdego żądania. Serwer API następnie sprawdza klucz API, aby zweryfikować tożsamość konsumenta przed zwróceniem żądanych danych.

Klucze API nie są tak skuteczne jak inne formy uwierzytelniania API, takie jak OAuth i JWT, ale nadal odgrywają ważną rolę w pomaganiu producentom API monitorować użycie, a jednocześnie chronić wrażliwe dane.

[1]: Konsument API to każda aplikacja, usługa lub użytkownik, który wchodzi w interakcję z API, aby uzyskać dostęp do jego funkcji lub danych. Wysyłają oni żądania do API, aby wykonać operacje, takie jak pobieranie, tworzenie, aktualizacja lub usuwanie zasobów. Konsumentami API mogą być aplikacje internetowe, aplikacje mobilne, inne serwery lub nawet indywidualni programiści, którzy używają API do integracji z innymi usługami lub do tworzenia nowych funkcji na podstawie istniejących platform.

Postman: Czym jest klucz API?

Przypadki użycia#

Kiedy ludzie omawiają przypadki użycia kluczy API, często wspominają o automatyzacji, udostępnianiu danych, testowaniu, rozwoju i kontroli bezpieczeństwa. Jednak są to dość techniczne tematy. W rzeczywistych scenariuszach, najczęstszym celem podczas budowy produktów jest integracja.

Przykład 1: Integracja z Zapier#

Zapier: Dodaj uwierzytelnienie za pomocą klucza API

Zapier to popularne narzędzie do automatyzacji, które łączy różne aplikacje internetowe. Podczas integracji aplikacji z Zapier, klucze API są używane do uwierzytelniania i autoryzacji dostępu do API aplikacji. Na przykład, jeśli chcesz zautomatyzować zadania między systemem CRM a narzędziem do e-mail marketingu, musisz wygenerować klucz API z systemu CRM i dostarczyć go do Zapier. Ten klucz jest następnie używany do uwierzytelniania żądań z Zapier do API systemu CRM, umożliwiając bezpieczny przepływ danych między dwoma systemami.

Przykład 2: Integracja ze Stripe#

Stripe korzysta z kluczy API do bezpiecznej integracji z różnymi platformami i aplikacjami. Użyj Panelu Dewelopera do tworzenia, ujawniania, usuwania i obracania kluczy API.

Osobiste tokeny dostępu (PAT)#

Osobisty token dostępu to kolejny podobny koncept, ale reprezentuje tożsamość i uprawnienia konkretnego użytkownika, jest dynamicznie generowany po udanym uwierzytelnieniu lub zalogowaniu i zazwyczaj ma ograniczony czas życia, ale może być odświeżany. Umożliwiają one szczegółową kontrolę dostępu do danych specyficznych dla użytkownika i funkcji, a są powszechnie używane w narzędziach CLI, skryptach lub osobistym dostępie API.

Jak działają PAT#

1. Tworzenie i zarządzanie: Użytkownicy generują PAT przez ustawienia konta na odpowiedniej platformie.
   • Na przykład, w GitHub, użytkownicy mogą tworzyć szczegółowe lub klasyczne PAT z określonymi uprawnieniami i datami wygaśnięcia.
   • W produktach Atlassian, takich jak Jira i Confluence, użytkownicy mogą tworzyć PAT z poziomu swoich ustawień profilu, określając nazwę tokena i opcjonalnie datę wygaśnięcia.
2. Użycie: PAT są używane jako tokeny typu bearer w nagłówku Authorization żądań API. Oznacza to, że są one dołączane do nagłówków HTTP w celu uwierzytelnienia żądania.
   • Umożliwiają bezpieczny dostęp do zasobów API, pozwalając użytkownikom wykonywać operacje takie jak tworzenie, odczytywanie, aktualizacja i usuwanie zasobów na podstawie uprawnień przypisanych do tokena.
   • PAT mogą być używane w wielu aplikacjach w ramach jednej platformy, oferując jednolity sposób zarządzania dostępem i uprawnieniami.
3. Cofnięcie i ustawianie wygaśnięcia:
   • PAT oferują zwiększone bezpieczeństwo, umożliwiając użytkownikom cofnięcie tokenów w przypadku ich skompromitowania, bez zmiany hasła konta.
   • Platformy często zalecają ustawienie dat wygaśnięcia PAT, aby zmniejszyć ryzyko nadużycia długowiecznych tokenów.

Przypadki użycia#

Istnieją dwa typowe scenariusze,

Automatyzacja i skrypty

Oznacza to, że gdy programista używa PAT do automatyzacji wdrażania kodu z repozytorium do środowiska produkcyjnego, redukując manualną interwencję i zapewniając spójność.

Na przykład użytkownicy GitHub mogą tworzyć PAT do autoryzacji operacji Git przez HTTPS i interakcji z REST API GitHub. Jest to przydatne dla programistów, którzy muszą zautomatyzować zadania takie jak klonowanie repozytoriów, wysyłanie commitów lub zarządzanie problemami i pull requestami.

Integracja z aplikacjami zewnętrznymi

Oznacza to umożliwienie bezpiecznej komunikacji między różnymi systemami i aplikacjami. Wygląda to podobnie do scenariusza, w którym używa się integracji za pomocą klucza API, ale PAT reprezentuje użytkownika, a nie klienta lub aplikację.

Na przykład kierownik projektu używa PAT do integracji narzędzia do zarządzania projektami z zewnętrznym systemem śledzenia problemów, co umożliwia płynną wymianę danych i synchronizację, tak jak w przypadku Atlassian (Jira i Confluence).

Powyższe scenariusze są bardziej związane z narzędziami dla programistów. Czy PAT są przydatne tylko dla tego rodzaju produktów? Nie. Oto dwa dodatkowe przykłady: jeden to system CMS, a drugi to narzędzie produktywności.

Przykład 1: Contentful#

Contentful: Osobiste tokeny dostępu

Contentful to platforma CMS typu headless, oferująca PAT jako alternatywę dla tokenów OAuth do uzyskiwania dostępu do ich API zarządzania treścią (CMA).

Kluczowe cechy:

• Użytkownicy mogą tworzyć wiele tokenów z różnymi zakresem i uprawnieniami.
• Tokeny są powiązane z kontem użytkownika, dziedzicząc jego uprawnienia.
• PAT są szczególnie przydatne do celów rozwoju i automatyzacji.

Przykład 2: Airtable#

Tworzenie osobistych tokenów dostępu | Wsparcie Airtable

Airtable — platforma do współpracy w chmurze, implementuje PAT w celu uzyskania dostępu do API.

Ich system pozwala na:

• Tworzenie wielu tokenów z różnym zakresem i poziomem dostępu.
• Tokeny mogą być ograniczone do konkretnych baz lub workspace'ów.
• Administratorzy korporacji mogą tworzyć tokeny z szerszym dostępem w całej organizacji.

Uwierzytelnianie maszyna-do-maszyny (M2M)#

M2M jest zaprojektowane do komunikacji serwis-serwis bez interwencji człowieka. Wywodzi się z idei, że nazwy użytkowników i hasła są niewystarczające do ochrony usług i są mało efektywne dla skutecznej automatyzacji.

Aplikacje maszyna-do-maszyny (M2M) adoptują teraz przepływ poświadczeń klienta, który jest zdefiniowany w Protokole autoryzacyjnym OAuth 2.0 RFC 6749. Może również wspierać podobne standardowe protokoły. Tak, uwierzytelnianie M2M jest bardziej restrykcyjne pod względem zgodności ze standardami otwartymi w porównaniu do PAT i kluczy API.

Uwierzytelnia aplikację lub usługę samą, a nie użytkownika, i często implementuje JWT (JSON Web Tokens) dla stateless uwierzytelniania. Zapewnia to bezpieczny sposób dla usług do wzajemnej interakcji w rozproszonych systemach.

Jak działa uwierzytelnianie maszyna-do-maszyny#

Działa ono w podobny sposób:

1. Poświadczenia klienta: Każda maszyna (lub usługa) ma unikalne ID klienta i sekret klienta.
2. Żądanie tokena: Usługa przesyła te poświadczenia do serwera autoryzacji.
3. Token dostępu: Po walidacji serwer autoryzacji wydaje token dostępu, często JWT (JSON Web Token).
4. Żądania API: Usługa używa tego tokena do uwierzytelniania i autoryzacji żądań API do innej usługi.
5. Walidacja: Odbierająca usługa waliduje token przed przyznaniem dostępu do swoich zasobów.

Przypadki użycia#

Oto zwięzły przykład użycia uwierzytelniania maszyna-do-maszyny (M2M) do komunikacji backend-backend:

Scenariusz: Usługa A musi uzyskać dostęp do danych z API Usługi B.

1. Konfiguracja:

   • Usługa A jest zarejestrowana jako klient z serwerem autoryzacji.
   • Usługa A otrzyma ID klienta i sekret klienta.

2. Uwierzytelnianie:

   • Usługa A prosi o token dostępu od serwera autoryzacji:

3. Wydanie tokena:

   • Serwer autoryzacji weryfikuje poświadczenia i wydaje JWT token dostępu.

4. Żądanie API:

   • Usługa A używa tokena do żądania danych z Usługi B:

5. Walidacja:

   • Usługa B sprawdza token u serwera autoryzacji.

6. Odpowiedź:

   • Jeśli token jest ważny, Usługa B zwraca żądane dane do Usługi A.

Ten proces umożliwia bezpieczną, automatyczną komunikację między Usługą A a Usługą B bez interwencji człowieka, używając przepływu poświadczeń klienta OAuth 2.0.

Komunikacja urządzenie-urządzenie

Komunikacja urządzenie-urządzenie, szczególnie w kontekście IoT (Internet of Things), silnie opiera się na uwierzytelnianiu maszyna-do-maszyny (M2M), aby zapewnić bezpieczną i efektywną wymianę danych.

Na przykład, w urządzeniach typu smart home, smart termostat komunikuje się z centralnym hubem automatyzacji domowej, aby dostosować ustawienia temperatury zgodnie z preferencjami użytkownika. Termostat używa uwierzytelniania M2M do bezpiecznego przesyłania danych do huba oraz odbierania poleceń, zapewniając, że tylko autoryzowane urządzenia mogą wchodzić w interakcje z systemem ogrzewania w domu.

Kluczowe podsumowanie#

Ok, dotarłeś do końca tego artykułu. Czy mogę otrzymać krótkie podsumowanie? Oczywiście! Oto kluczowe punkty:

1. Zakres: Klucze API są szerokie, PAT (Osobiste Tokeny Dostępu) są specyficzne dla użytkownika, a tokeny M2M (Maszyna-Do-Maszyny) są specyficzne dla usługi.
2. Czas życia: Klucze API są długowieczne, PAT mają krótszy czas życia, a czas życia tokenów M2M może się różnić.
3. Reprezentacja: Klucze API są nieprzejrzystymi ciągami, PAT mogą być nieprzejrzyste lub mają strukturę, a tokeny M2M często używają JWT.
4. Przypadek użycia: Klucze API są do prostego dostępu do API, PAT są do operacji zorientowanych na użytkownika, a tokeny M2M są do komunikacji serwis-serwis.