Udostępnij za pomocą

Uwierzytelnianie i autoryzacja interfejsów API w usłudze Azure API Management

DOTYCZY: Wszystkich poziomów zarządzania API

Ten artykuł stanowi wprowadzenie do zaawansowanego, elastycznego zestawu funkcji w usłudze API Management, które ułatwiają zabezpieczanie dostępu użytkowników do zarządzanych interfejsów API.

Uwierzytelnianie interfejsu API i autoryzacja w usłudze API Management obejmują zabezpieczanie kompleksowej komunikacji aplikacji klienckich z bramą usługi API Management oraz za pośrednictwem interfejsów API zaplecza. W wielu środowiskach klienta protokół OAuth 2.0 jest preferowanym protokołem autoryzacji interfejsu API. Usługa API Management obsługuje autoryzację protokołu OAuth 2.0 między klientem a bramą usługi API Management między bramą a interfejsem API zaplecza lub niezależnie.

Diagram przedstawiający punkty interakcji na potrzeby zabezpieczania interfejsów API.

Usługa API Management obsługuje inne mechanizmy uwierzytelniania po stronie klienta i po stronie usługi, które uzupełniają protokół OAuth 2.0 lub które są przydatne, gdy autoryzacja OAuth 2.0 dla interfejsów API nie jest możliwa. Wybór spośród tych opcji zależy od dojrzałości środowiska interfejsu API organizacji, wymagań dotyczących zabezpieczeń i zgodności oraz podejścia organizacji do ograniczania typowych zagrożeń interfejsu API.

Important

Zabezpieczanie dostępu użytkowników do interfejsów API jest jednym z wielu zagadnień dotyczących zabezpieczania środowiska usługi API Management. Aby uzyskać więcej informacji, zobacz Punkt odniesienia zabezpieczeń platformy Azure dla usługi API Management.

Note

Inne składniki usługi API Management mają oddzielne mechanizmy zabezpieczania i ograniczania dostępu użytkowników:

  • Do zarządzania wystąpieniem usługi API Management za pośrednictwem płaszczyzny sterowania platformy Azure usługa API Management opiera się na identyfikatorze Entra firmy Microsoft i kontroli dostępu opartej na rolach (RBAC) na platformie Azure.
  • Portal deweloperów usługi API Management obsługuje kilka opcji ułatwiających bezpieczne rejestrowanie i logowanie użytkownika.

Uwierzytelnianie a autoryzacja

Oto krótkie wyjaśnienie uwierzytelniania i autoryzacji w kontekście dostępu do interfejsów API:

  • Uwierzytelnianie: proces weryfikowania tożsamości użytkownika lub aplikacji, który uzyskuje dostęp do interfejsu API. Uwierzytelnianie można przeprowadzić za pomocą poświadczeń, takich jak nazwa użytkownika i hasło, certyfikat lub logowanie jednokrotne (SSO) lub inne metody.

  • Autoryzacja: proces określania, czy użytkownik lub aplikacja ma uprawnienia dostępu do określonego interfejsu API, często za pośrednictwem protokołu opartego na tokenach, takiego jak OAuth 2.0.

Note

Aby uzupełnić uwierzytelnianie i autoryzację, należy również zabezpieczyć dostęp do interfejsów API przy użyciu protokołu TLS w celu ochrony poświadczeń lub tokenów używanych do uwierzytelniania lub autoryzacji.

Pojęcia dotyczące protokołu OAuth 2.0

OAuth 2.0 to standardowa struktura autoryzacji, która jest powszechnie używana do zabezpieczania dostępu do zasobów, takich jak internetowe interfejsy API. Protokół OAuth 2.0 ogranicza akcje dotyczące tego, co aplikacja kliencka może wykonywać w zasobach w imieniu użytkownika, bez udostępniania poświadczeń użytkownika. Chociaż protokół OAuth 2.0 nie jest protokołem uwierzytelniania, często jest używany z protokołem OpenID Connect (OIDC), który rozszerza protokół OAuth 2.0, zapewniając uwierzytelnianie użytkowników i funkcje logowania jednokrotnego.

Przepływ OAuth

Co się stanie, gdy aplikacja kliencka wywołuje interfejs API z żądaniem zabezpieczonym przy użyciu protokołów TLS i OAuth 2.0? Poniżej przedstawiono skrócony przykładowy przepływ:

  • Klient (aplikacja wywołująca lub element nośny) uwierzytelnia się przy użyciu poświadczeń dostawcy tożsamości.

  • Klient uzyskuje token dostępu ograniczony czasowo (token internetowy JSON lub JWT) z serwera autoryzacji dostawcy tożsamości.

    Dostawca tożsamości (na przykład Microsoft Entra ID) jest wystawcą tokenu, a token zawiera oświadczenie odbiorców , które autoryzuje dostęp do serwera zasobów (na przykład do interfejsu API zaplecza lub do samej bramy usługi API Management).

  • Klient wywołuje interfejs API i prezentuje token dostępu; na przykład w nagłówku autoryzacji.

  • Serwer zasobów weryfikuje token dostępu. Walidacja to złożony proces, który obejmuje sprawdzenie, czy oświadczenia wystawcy i odbiorców zawierają oczekiwane wartości.

  • Na podstawie kryteriów weryfikacji tokenu dostęp do zasobów interfejsu API zaplecza systemu jest przyznawany.

W zależności od typu aplikacji klienckiej i scenariuszy wymagane są różne przepływy autoryzacji do żądania tokenów i zarządzania nimi. Na przykład przepływ kodu autoryzacji i typ udzielania są często używane w aplikacjach wywołujących internetowe interfejsy API. Dowiedz się więcej o przepływach protokołu OAuth i scenariuszach aplikacji w usłudze Microsoft Entra ID.

Scenariusze autoryzacji protokołu OAuth 2.0 w usłudze API Management

Scenariusz 1 — aplikacja kliencka autoryzuje bezpośrednio do zaplecza

Typowy scenariusz autoryzacji polega na tym, że aplikacja wywołująca żąda bezpośredniego dostępu do interfejsu API zaplecza i przedstawia token OAuth 2.0 w nagłówku autoryzacji do bramki. Usługa Azure API Management działa następnie jako "przezroczysty" serwer proxy między klientem a interfejsem API zaplecza i przekazuje token bez zmian do zaplecza. Zakres tokenu dostępu jest między wywoływaną aplikacją a interfejsem API zaplecza.

Na poniższej ilustracji przedstawiono przykład, w którym identyfikator Entra firmy Microsoft jest dostawcą autoryzacji. Aplikacja kliencka może być aplikacją jednostronicową (SPA).

Diagram przedstawiający komunikację OAuth, w której odbiorcy są zapleczem.

Mimo że token dostępu wysyłany wraz z żądaniem HTTP jest przeznaczony dla interfejsu API zaplecza, usługa API Management nadal umożliwia ochronę w głębi systemu. Na przykład skonfiguruj zasady, aby zweryfikować JWT, odrzucając żądania dostarczane bez tokenu lub tokenu, który jest nieprawidłowy dla zamierzonego interfejsu API zaplecza. Możesz również skonfigurować usługę API Management, aby sprawdzić inne oświadczenia zainteresowań wyodrębnione z tokenu.

Note

Jeśli w ten sposób zabezpieczysz interfejs API uwidoczniony za pośrednictwem usługi Azure API Management za pomocą protokołu OAuth 2.0, możesz skonfigurować usługę API Management w celu wygenerowania prawidłowego tokenu do celów testowych w imieniu użytkownika konsoli testowej witryny Azure Portal lub portalu deweloperów. Musisz dodać serwer OAuth 2.0 do wystąpienia usługi API Management i włączyć ustawienia autoryzacji protokołu OAuth 2.0 w interfejsie API. Aby uzyskać więcej informacji, zobacz How to authorize test console of developer portal by configuring OAuth 2.0 user authorization (Jak autoryzować konsolę testową portalu deweloperów przez skonfigurowanie autoryzacji użytkownika OAuth 2.0).

Example:

Tip

W specjalnym przypadku, gdy dostęp do interfejsu API jest chroniony przy użyciu identyfikatora Entra firmy Microsoft, można skonfigurować zasady validate-azure-ad-token na potrzeby weryfikacji tokenu.

Scenariusz 2 — aplikacja kliencka autoryzuje usługę API Management

W tym scenariuszu usługa API Management działa w imieniu API, a aplikacja wywołująca żąda dostępu do wystąpienia tej usługi. Zakres tokenu dostępu jest między aplikacją wywołującą a bramą usługi API Management. W zarządzaniu API skonfiguruj politykę (validate-jwt lub validate-azure-ad-token), aby zweryfikować token, zanim brama przekaże żądanie do backendu. Oddzielny mechanizm zwykle zabezpiecza połączenie między bramą a interfejsem API zaplecza.

W poniższym przykładzie identyfikator Entra firmy Microsoft jest ponownie dostawcą autoryzacji, a wzajemne uwierzytelnianie TLS (mTLS) zabezpiecza połączenie między bramą a zapleczem.

Diagram przedstawiający komunikację OAuth, gdzie odbiorcą jest brama zarządzania API.

Istnieją różne powody, aby to zrobić. Przykład:

  • Zaplecze to starszy interfejs API, którego nie można zaktualizować w celu obsługi protokołu OAuth

    Najpierw należy skonfigurować usługę API Management w celu zweryfikowania tokenu (co najmniej sprawdzanie oświadczeń wystawcy i odbiorców). Po weryfikacji użyj jednej z kilku opcji dostępnych do zabezpieczenia połączeń pochodzących z usługi API Management, takich jak wzajemne uwierzytelnianie TLS (mTLS). Zobacz Opcje po stronie usługi w dalszej części tego artykułu.

  • Kontekst wymagany przez zaplecze nie jest możliwy do ustanowienia z obiektu wywołującego

    Zarządzanie API, po pomyślnym zweryfikowaniu tokenu otrzymanego od dzwoniącego, musi uzyskać token dostępu dla interfejsu API zaplecza, używając własnego kontekstu lub kontekstu pochodzącego z aplikacji wywołującej. Ten scenariusz można wykonać przy użyciu jednego z następujących elementów:

    • Niestandardowa polityka, taka jak wyślij-żądanie, aby uzyskać token dostępu obowiązujący do interfejsu API backendu od skonfigurowanego dostawcy tożsamości.

    • Własna tożsamość wystąpienia usługi API Management, przekazująca token z przypisanej przez system lub przypisanej przez użytkownika tożsamości zarządzanej zasobu usługi API Management do interfejsu API zaplecza.

  • Organizacja chce przyjąć ustandaryzowane podejście do autoryzacji

    Niezależnie od mechanizmów uwierzytelniania i autoryzacji w zapleczach API, organizacje mogą wybrać zastosowanie protokołu OAuth 2.0 w celu uzyskania standardowego podejścia do autoryzacji na froncie. Brama usługi API Management może umożliwić spójną konfigurację autoryzacji i typowe środowisko dla użytkowników interfejsu API w miarę rozwoju zaplecza organizacji.

Scenariusz 3: API Management autoryzuje do backendu

W przypadku połączeń zarządzanych (wcześniej nazywanych autoryzacjami) używasz menedżera poświadczeń w usłudze API Management, aby autoryzować dostęp do co najmniej jednego zaplecza lub usług SaaS, takich jak LinkedIn, GitHub lub inne zaplecza zgodne z protokołem OAuth 2.0. W tym scenariuszu użytkownik lub aplikacja kliencka wysyła żądanie do bramy usługi API Management z dostępem do bramy kontrolowanym przy użyciu dostawcy tożsamości lub innych opcji po stronie klienta. Następnie za pomocą konfiguracji zasad użytkownik lub aplikacja kliencka deleguje uwierzytelnianie zaplecza i autoryzację do usługi API Management.

W poniższym przykładzie klucz subskrypcji jest używany między klientem a bramą, a usługa GitHub jest dostawcą poświadczeń dla interfejsu API zaplecza.

Diagram przedstawiający autoryzację do usługi SaaS zaplecza przy użyciu połączenia zarządzanego w menedżerze poświadczeń.

W przypadku połączenia z dostawcą poświadczeń usługa API Management uzyskuje i odświeża tokeny dostępu do interfejsu API w przepływie OAuth 2.0. Połączenia upraszczają zarządzanie tokenami w wielu scenariuszach, takich jak:

  • Aplikacja kliencka może wymagać autoryzacji do wielu zapleczy SaaS w celu rozpoznawania wielu pól przy użyciu narzędzi rozpoznawania języka GraphQL.
  • Użytkownicy uwierzytelniają się w usłudze API Management za pomocą logowania jednokrotnego od dostawcy tożsamości, ale autoryzują się wobec zaplecza usług SaaS (takiego jak LinkedIn) za pomocą wspólnego konta organizacyjnego.
  • Aplikacja kliencka (lub bot) musi uzyskiwać dostęp do zabezpieczonych zasobów online zaplecza w imieniu uwierzytelnionego użytkownika (na przykład sprawdzania wiadomości e-mail lub składania zamówienia).

Examples:

Inne opcje zabezpieczania interfejsów API

Mimo że autoryzacja jest preferowana, a protokół OAuth 2.0 stał się dominującą metodą włączania silnej autoryzacji dla interfejsów API, usługa API Management udostępnia kilka innych mechanizmów zabezpieczania lub ograniczania dostępu między klientem a bramą (po stronie klienta) lub między bramą a zapleczem (po stronie usługi). W zależności od wymagań organizacji można ich użyć do uzupełnienia protokołu OAuth 2.0. Alternatywnie skonfiguruj je niezależnie, jeśli wywoływane aplikacje lub interfejsy API zaplecza są starsze lub nie obsługują jeszcze protokołu OAuth 2.0.

Opcje po stronie klienta

Mechanism Description Considerations
mTLS Zweryfikuj certyfikat przedstawiony przez klienta łączącego i sprawdź właściwości certyfikatu względem certyfikatu zarządzanego w usłudze API Management Certyfikat można przechowywać w magazynie kluczy.
Ograniczanie adresów IP wywołujących Filtruj (zezwalaj/odmawiaj) wywołań z określonych adresów IP lub zakresów adresów. Służy do ograniczania dostępu do niektórych użytkowników lub organizacji albo do ruchu z usług nadrzędnych.
Klucz subskrypcji Ograniczanie dostępu do co najmniej jednego interfejsu API na podstawie subskrypcji usługi API Management Zalecamy używanie klucza subskrypcji (API) oprócz innej metody uwierzytelniania lub autoryzacji. Samodzielnie klucz subskrypcji nie jest silną formą uwierzytelniania, ale użycie klucza subskrypcji może być przydatne w niektórych scenariuszach; na przykład śledzenie użycia interfejsu API poszczególnych klientów lub udzielanie dostępu do określonych produktów interfejsu API.

Tip

W celu zapewnienia głębokiej obrony zdecydowanie zalecamy wdrożenie zapory aplikacji internetowej przed wystąpieniem usługi API Management. Na przykład użyj usługi Azure Application Gateway lub usługi Azure Front Door.

Opcje po stronie usługi

Mechanism Description Considerations
Uwierzytelnianie tożsamości zarządzanej Aby się uwierzytelnić w interfejsie API backendu, użyj systemowo przypisanej lub użytkownikowo przypisanej tożsamości zarządzanej. Zalecane w przypadku kontrolowanego dostępu do chronionego zasobu serwera przez uzyskanie tokena z Microsoft Entra ID.
Uwierzytelnianie certyfikatu Uwierzytelnij się w interfejsie API zaplecza za pomocą certyfikatu klienta. Certyfikat można przechowywać w magazynie kluczy.
Uwierzytelnianie podstawowe Proszę uwierzytelnić się w backendowym API używając nazwy użytkownika oraz hasła, które są przekazywane za pośrednictwem nagłówka autoryzacji. Zniechęcono, jeśli są dostępne bardziej bezpieczne opcje uwierzytelniania (na przykład tożsamość zarządzana, certyfikaty, menedżer poświadczeń). Jeśli zostaną wybrane, użyj nazwanych wartości do podania poświadczeń, z tajemnicami chronionymi w magazynie kluczy.

Powiązana zawartość

  • Last updated on