Uwierzytelnianie i autoryzacja do interfejsów API w usłudze Azure API Management
DOTYCZY: Wszystkie warstwy usługi API Management
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 i autoryzacja interfejsu API w API Management obejmują zabezpieczenie kompleksowej komunikacji aplikacji klienckich z bramą 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.
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.
Ważne
Zabezpieczanie dostępu użytkowników do interfejsów API to jedno z wielu zagadnień związanych z zabezpieczaniem środowiska usługi API Management. Aby uzyskać więcej informacji, zobacz Punkt odniesienia zabezpieczeń platformy Azure dla usługi API Management.
Uwaga
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óra 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.
Uwaga
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, jest często używany z protokołem OpenID Połączenie (OIDC), który rozszerza protokół OAuth 2.0, zapewniając uwierzytelnianie użytkowników i funkcję 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 przedstawia token dostępu — na przykład w nagłówku autoryzacji.
Serwer zasobów weryfikuje token dostępu. Walidacja to złożony proces obejmujący sprawdzenie, czy wystawca i oświadczenia odbiorców zawierają oczekiwane wartości.
Na podstawie kryteriów weryfikacji tokenu dostęp do zasobów interfejsu API zaplecza jest następnie udzielany.
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 wywołanie aplikacji żąda dostępu bezpośrednio do interfejsu API zaplecza i przedstawia token OAuth 2.0 w nagłówku autoryzacji do bramy. Usługa Azure API Management działa następnie jako "przezroczysty" serwer proxy między obiektem wywołującym i 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).
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 w celu zweryfikowania JWT, odrzucania żądań dostarczanych 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.
Uwaga
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).
Przykład:
Napiwek
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 interfejsu API, a wywołująca aplikacja żąda dostępu do wystąpienia usługi API Management. Zakres tokenu dostępu jest między aplikacją wywołującą a bramą usługi API Management. W usłudze API Management skonfiguruj zasady (validate-jwt lub validate-azure-ad-token), aby zweryfikować token, zanim brama przekaże żądanie do zaplecza. 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.
Istnieją różne powody, aby to zrobić. Na 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
Po pomyślnym zweryfikowaniu tokenu otrzymanego od obiektu wywołującego usługa API usługi API zaplecza musi uzyskać token dostępu dla interfejsu API zaplecza przy użyciu 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:
Niestandardowe zasady, takie jak żądanie wysyłania w celu uzyskania tokenu dostępu do wewnątrz prawidłowego dla interfejsu API zaplecza od skonfigurowanego dostawcy tożsamości.
Własna tożsamość wystąpienia usługi API Management — przekazywanie tokenu 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 interfejsu API organizacje mogą wybrać zbieżność protokołu OAuth 2.0 w celu uzyskania standardowego podejścia do autoryzacji na frontonie. 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. Autoryzacje usługi API Management do zaplecza
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.
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łączenie ions 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ą dostawcę SaaS zaplecza (na przykład LinkedIn) przy użyciu 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).
Przykłady:
- Konfigurowanie menedżera poświadczeń — interfejs API programu Microsoft Graph
- Konfigurowanie menedżera poświadczeń — interfejs API usługi GitHub
- Konfigurowanie menedżera poświadczeń — delegowany dostęp użytkownika do interfejsów API zaplecza
Inne opcje zabezpieczania interfejsów API
Chociaż 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 mogą one być używane 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
| Mechanizm | opis | Zagadnienia do rozważenia |
|---|---|---|
| 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że być przechowywany 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. 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. |
Napiwek
Aby uzyskać szczegółową ochronę, zdecydowanie zaleca się wdrożenie zapory aplikacji internetowej nadrzędnej wystąpienia usługi API Management. Na przykład użyj aplikacja systemu Azure Gateway lub Azure Front Door.
Opcje po stronie usługi
| Mechanizm | opis | Zagadnienia do rozważenia |
|---|---|---|
| Uwierzytelnianie tożsamości zarządzanej | Uwierzytelnianie w interfejsie API zaplecza przy użyciu tożsamości zarządzanej przypisanej przez system lub przypisanej przez użytkownika. | Zalecane w przypadku dostępu w zakresie do chronionego zasobu zaplecza przez uzyskanie tokenu z identyfikatora Entra firmy Microsoft. |
| Uwierzytelnianie certyfikatu | Uwierzytelnianie w interfejsie API zaplecza przy użyciu certyfikatu klienta. | Certyfikat może być przechowywany w magazynie kluczy. |
| Uwierzytelnianie podstawowe | Uwierzytelnianie w interfejsie API zaplecza przy użyciu nazwy użytkownika i hasła przekazywanego za pośrednictwem nagłówka autoryzacji. | Zniechęcony, jeśli są dostępne lepsze opcje. |
Następne kroki
- Dowiedz się więcej o uwierzytelnianiu i autoryzacji w Platforma tożsamości Microsoft.
- Dowiedz się, jak ograniczyć zagrożenia bezpieczeństwa interfejsu API OWASP przy użyciu usługi API Management.