Programowe uwierzytelnianie: klucz API, osobisty token dostępu i przepływ poświadczeń OAuth klienta

Tło#

W rozwoju oprogramowania, kiedy musimy programowo uzyskać dostęp do zasobów API za pomocą poleceń CLI lub ustanowić komunikację między usługami backendowymi, istnieją zazwyczaj trzy mechanizmy uwierzytelniania szeroko stosowane przez nas, deweloperów: klucz API, Osobisty Token Dostępu (PAT) i przepływ poświadczeń OAuth klienta (brandingowany jako Machine-to-Machine w Logto). Ale jakie są różnice między nimi? Jaka jest najlepsza sytuacja, w której można zastosować każdą z tych metod? W tym wpisie na blogu zagłębimy się w podobieństwa, różnice i przedstawimy wskazówki, kiedy używać każdego z nich w różnych scenariuszach.

Definicje#

• Klucz API: Prosty ciąg znaków, który może uwierzytelnić Twoje żądanie do zasobu API.
• Osobisty Token Dostępu (PAT): Również prosty ciąg znaków, ale reprezentuje użytkownika podczas używania go do uwierzytelniania do zasobu API. Jest to delegacja użytkownika.
• Logto Machine-to-Machine (Logto M2M): Standardowy przepływ poświadczeń OAuth klienta, który wymaga wcześniejszej rejestracji klienta i wymaga użycia identyfikatora i sekretu klienta do wymiany na token dostępu. W ten sposób poświadczenia Logto M2M reprezentują zaufanego klienta, a natura przepływu poświadczeń OAuth klienta sprawia, że jest stosunkowo skomplikowane podczas używania.

Podobieństwa#

1. Cel uwierzytelniania#

• Wszystkie trzy, klucz API, PAT i Logto M2M, służą głównemu celowi uwierzytelniania użytkownika lub aplikacji w celu uzyskania dostępu do konkretnej usługi lub zasobu. Działają jako poświadczenia potwierdzające tożsamość żądającego i są zazwyczaj używane w scenariuszach z poleceniami CLI lub komunikacją backend-to-backend.

2. Środki bezpieczeństwa#

• Wszystkie te trzy metody uwierzytelniania powinny być traktowane z naciskiem na bezpieczeństwo. Deweloperzy muszą zapewnić bezpieczne przechowywanie i przesyłanie, aby zapobiec nieautoryzowanemu dostępowi.

Różnice#

1. Kontekst użytkownika#

• Klucz API nie identyfikuje podmiotu ani nie dostarcza żadnych informacji autoryzacyjnych. Dlatego klucze API są często używane do uzyskiwania dostępu do danych publicznych lub zasobów anonimowo. Wszystkie usługi NIE są wspierane przez użycie kluczy API.
• PAT to tożsamości użytkowników i będzie Cię reprezentować, gdy będzie używane do żądania zasobu API. W niektórych systemach PATy nie są dozwolone do uzyskiwania dostępu do określonych usług. Np. Publikowanie pakietów NuGet do kanału Azure Artifacts.
• Poświadczenia Logto M2M mogą być używane tylko przez zaufanych klientów. Klient musi być wcześniej zarejestrowany, aby został uwierzytelniony. Podczas używania poświadczeń Logto M2M, reprezentują one zaufanego klienta, a nie użytkownika, kto ich używa.

2. Granulacja uprawnień#

• PAT i poświadczenia Logto M2M zazwyczaj oferują bardziej szczegółową kontrolę nad uprawnieniami w porównaniu do klucza API, umożliwiając precyzyjną kontrolę nad tym, jakie działania mogą być wykonywane.

3. Format tokenu#

• Klucz API i PAT są zazwyczaj nieprzejrzystymi ciągami znaków, prostymi i zrozumiałymi.
• Tokeny dostępu wydawane przez mechanizm Logto M2M są zazwyczaj w formacie JWT.

4. Przepływ autoryzacji#

• Klucz API i PAT są generowanymi przez system nieprzejrzystymi ciągami znaków, bez zaangażowanych przepływów uwierzytelniania podczas procesu. Na przykład, możesz wywołać Google Cloud natural language API w ten sposób:

• Logto M2M wykorzystuje standardowy przepływ poświadczeń OAuth 2.0. Każdy klient musi uzyskać parę ID klienta i sekret klienta wcześniej, aby później mógł wymienić je na token dostępu. Następnie klient używa tokenu dostępu do uzyskiwania dostępu do zasobu API.

Kiedy używać każdego z nich#

Klucz API#

• Komunikacja serwisowa: Klucze API są odpowiednie w sytuacjach, gdy aplikacje muszą bezpośrednio komunikować się z API poprzez CLIs. Np. Wywoływanie API OpenAI.
• Publiczne API: Podczas eksponowania API dla ogółu, klucze API zapewniają prostą metodę kontroli dostępu.
• Uproszczone wdrożenie: Dla szybkich i prostych potrzeb uwierzytelniania, szczególnie w fazie rozwoju. W przeciwieństwie do Logto M2M, klucze API nie wymagają wcześniejszej rejestracji klienta ani wymiany na token dostępu. Wystarczy, że przekażesz swój klucz API jako parametr w żądaniu i po prostu działa.

Osobisty Token Dostępu (PAT)#

• Działania specyficzne dla użytkownika: Gdy aplikacja musi wykonywać działania w imieniu użytkownika.
• Szczegółowa kontrola dostępu (użytkownik): Gdy wymagana jest precyzyjna kontrola nad działaniami, jakie użytkownik może wykonywać.

Logto Machine-to-Machine (Logto M2M)#

• Bezpieczeństwo: Logto M2M jest idealne w sytuacjach, gdy tylko zaufani klienci są dopuszczeni do uzyskiwania dostępu do usług backendowych.
• Szczegółowa kontrola dostępu (klient): Gdy wymagana jest precyzyjna kontrola nad działaniami, jakie aplikacja może wykonywać.

Podsumowanie#

Podsumowując, wybór między kluczami API, PATami i Logto M2M zależy od konkretnych wymagań twojej aplikacji, czy to zaangażowanie działań specyficznych dla użytkownika, komunikacja między maszynami, czy kombinacja obu. Oceń potrzeby w zakresie bezpieczeństwa i funkcjonalności, aby określić najbardziej odpowiednią metodę uwierzytelniania dla twojego przypadku użycia.

Mechanizm Logto M2M pozwala użytkownikom ustawiać szczegółowe kontrole dostępu w funkcji RBAC (Kontrola Dostępu na Bazie Ról). Planujemy także wsparcie klucza API i PAT w najbliższej przyszłości. Śledź nasze aktualizacje funkcji!