Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
DOTYCZY: Wszystkie warstwy usługi API Management
Ten artykuł zawiera szczegółowe informacje o przepływach procesów zarządzania połączeniami OAuth 2.0 przy użyciu menedżera poświadczeń w usłudze Azure API Management. Przepływy procesów są podzielone na dwie części: zarządzanie i czas działania.
Aby zapoznać się z informacjami na temat menedżera poświadczeń w usłudze API Management, zobacz Informacje o menedżerze poświadczeń i poświadczeniach interfejsu API w usłudze API Management.
Zarządzanie połączeniami
Część zarządzania połączeniami w menedżerze poświadczeń zajmuje się konfigurowaniem i konfigurowaniem dostawcy poświadczeń dla tokenów OAuth 2.0, włączaniem przepływu zgody dla dostawcy i konfigurowaniem co najmniej jednego połączenia z dostawcą poświadczeń w celu uzyskania dostępu do poświadczeń.
Na poniższej ilustracji przedstawiono podsumowanie przepływu procesu tworzenia połączenia w usłudze API Management, które używa typu udzielania kodu autoryzacji.
Krok | Opis |
---|---|
1 | Klient wysyła żądanie utworzenia dostawcy poświadczeń |
2 | Zostanie utworzony dostawca poświadczeń, a odpowiedź zostanie wysłana z powrotem |
3 | Klient wysyła żądanie utworzenia połączenia |
4 | Połączenie jest tworzone, a odpowiedź jest wysyłana z powrotem z informacjami, że połączenie nie jest "połączone" |
5 | Klient wysyła żądanie pobrania adresu URL logowania w celu uruchomienia zgody protokołu OAuth 2.0 u dostawcy poświadczeń. Żądanie zawiera adres URL po przekierowaniu, który ma być używany w ostatnim kroku |
6 | Odpowiedź jest zwracana przy użyciu adresu URL logowania, który powinien służyć do uruchomienia przepływu zgody. |
7 | Klient otwiera przeglądarkę z adresem URL logowania podanym w poprzednim kroku. Przeglądarka jest przekierowywana do przepływu zgody dostawcy poświadczeń OAuth 2.0 |
8 | Po zatwierdzeniu zgody przeglądarka jest przekierowywana przy użyciu kodu autoryzacji do adresu URL przekierowania skonfigurowanego u dostawcy poświadczeń |
9 | Zarządzanie API używa kodu autoryzacji do pobierania tokenów dostępu i odświeżania. |
10 | Usługa API Management odbiera tokeny i szyfruje je |
11 | Usługa API Management przekierowuje do podanego adresu URL z kroku 5 |
Dostawca poświadczeń
Podczas konfigurowania dostawcy poświadczeń można wybrać między różnymi dostawcami protokołu OAuth i typami udzielania (kod autoryzacji lub poświadczenia klienta). Każdy dostawca wymaga określonych konfiguracji. Ważne kwestie, o których należy pamiętać:
- Konfiguracja dostawcy poświadczeń może mieć tylko jeden typ udzielenia.
- Jedna konfiguracja dostawcy poświadczeń może mieć wiele połączeń.
Uwaga
W przypadku dostawcy ogólnego protokołu OAuth 2.0 można używać innych dostawców tożsamości obsługujących standardy przepływu OAuth 2.0 .
Podczas konfigurowania dostawcy poświadczeń menedżer poświadczeń w tle tworzy magazyn poświadczeń używany do buforowania tokenów dostępu OAuth 2.0 dostawcy i tokenów odświeżania.
Połączenie z dostawcą poświadczeń
Aby uzyskać dostęp do dostawcy i używać tokenów, aplikacje klienckie muszą mieć połączenie z dostawcą poświadczeń. Określone połączenie jest dozwolone przez zasady dostępu na podstawie tożsamości Microsoft Entra ID. Dla dostawcy można skonfigurować wiele połączeń.
Proces konfigurowania połączenia różni się w zależności od skonfigurowanego udzielenia i jest specyficzny dla konfiguracji dostawcy poświadczeń. Na przykład, jeśli chcesz skonfigurować Microsoft Entra ID do używania obu typów przydziału, potrzebne są dwie konfiguracje dostawców poświadczeń. Poniższa tabela zawiera podsumowanie dwóch typów dotacji.
Typ udzielenia | Opis |
---|---|
Kod autoryzacji | Powiązana z kontekstem użytkownika, co oznacza, że użytkownik musi wyrazić zgodę na połączenie. Dopóki token odświeżania jest prawidłowy, przez usługę API Management mogą być pobierane nowe tokeny dostępu i odświeżania. Jeśli token odświeżania stanie się nieprawidłowy, użytkownik musi ponownie uwierzytelnić. Wszyscy dostawcy poświadczeń obsługują kod autoryzacji. Dowiedz się więcej |
Poświadczenia klienta | Nie jest powiązany z użytkownikiem i jest często używany w scenariuszach aplikacji do aplikacji. W przypadku typu udzielania poświadczeń klienta nie jest wymagana żadna zgoda, a połączenie nie staje się nieprawidłowe. Dowiedz się więcej |
Zgoda
W przypadku połączeń opartych na typie udzielania kodu autoryzacji należy uwierzytelnić dostawcę i wyrazić zgodę na autoryzację. Po pomyślnym zalogowaniu i autoryzacji przez dostawcę poświadczeń dostawca zwraca prawidłowy dostęp i tokeny odświeżania, które są szyfrowane i zapisywane przez usługę API Management.
Zasady dostępu
Dla każdego połączenia należy skonfigurować co najmniej jedną zasady dostępu . Zasady dostępu określają, które tożsamości usługi Microsoft Entra ID mogą uzyskać dostęp do twoich poświadczeń w trakcie działania. Połączenia obecnie obsługują dostęp przy użyciu jednostek usługi, tożsamości, użytkowników i grup wystąpienia usługi API Management.
Tożsamość | Opis | Korzyści | Zagadnienia do rozważenia |
---|---|---|---|
Podmiot usługi | Tożsamość, której tokeny mogą służyć do uwierzytelniania i udzielania dostępu do określonych zasobów platformy Azure, gdy organizacja korzysta z identyfikatora Microsoft Entra. Korzystając z jednostki usługi, organizacje unikają tworzenia fikcyjnych użytkowników do zarządzania uwierzytelnianiem, gdy muszą uzyskać dostęp do zasobu. Główna tożsamość usługi to tożsamość Microsoft Entra, która reprezentuje zarejestrowaną aplikację Microsoft Entra. | Umożliwia ściślejszy dostęp do scenariuszy połączenia i delegowania użytkowników. Nie jest powiązany z konkretnym wystąpieniem usługi API Management. Opiera się na identyfikatorze Entra firmy Microsoft na potrzeby wymuszania uprawnień. | Uzyskanie kontekstu autoryzacji wymaga tokenu Microsoft Entra ID. |
Tożsamość zarządzana <Your API Management instance name> |
Ta opcja odpowiada tożsamości zarządzanej powiązanej z wystąpieniem usługi API Management. | Domyślnie dostęp jest udzielany systemowo przypisanej tożsamości zarządzanej dla danej instancji usługi zarządzania API. | Tożsamość jest ściśle powiązana z instancją usługi API Management. Każda osoba z dostępem współautora do wystąpienia usługi API Management może uzyskać dostęp do dowolnego połączenia udzielającego uprawnień tożsamości zarządzanej. |
Użytkownicy lub grupy | Użytkownicy lub grupy w dzierżawie Microsoft Entra ID. | Umożliwia ograniczenie dostępu do określonych użytkowników lub grup użytkowników. | Wymaga, aby użytkownicy mieli konto Microsoft Entra ID. |
Czas działania połączeń
Część środowiska uruchomieniowego wymaga skonfigurowania interfejsu API OAuth 2.0 dla zaplecza z polityką get-authorization-context
. W czasie wykonywania zasada pobiera i przechowuje tokeny dostępu i odświeżania ze skonfigurowanego przez usługę API Management magazynu poświadczeń dla dostawcy. Kiedy połączenie przychodzi do API Management i zasada get-authorization-context
jest zastosowana, najpierw sprawdza, czy istniejący token autoryzacji jest prawidłowy. Jeśli token autoryzacji wygasł, usługa API Management używa przepływu OAuth 2.0 w celu odświeżenia przechowywanych tokenów od dostawcy poświadczeń. Następnie token dostępu jest używany do autoryzowania dostępu do usługi zaplecza.
Podczas wykonywania zasad dostęp do tokenów jest również weryfikowany przy użyciu zasad dostępu.
Na poniższej ilustracji przedstawiono przykładowy schemat procesu pobierania i przechowywania tokenów autoryzacji i odświeżania w oparciu o połączenie korzystające z typu udzielania kodu autoryzacji. Po pobraniu tokenów wykonywane jest wywołanie do interfejsu API systemu zaplecza.
Krok | Opis |
---|---|
1 | Klient wysyła żądanie do instancji usługi API Management |
2 | Zasady get-authorization-context sprawdzają, czy token dostępu jest prawidłowy dla bieżącego połączenia |
3 | Jeśli token dostępu wygasł, ale token odświeżania jest prawidłowy, usługa API Management próbuje pobrać nowy dostęp i odświeżyć tokeny od skonfigurowanego dostawcy poświadczeń |
4 | Dostawca poświadczeń zwraca zarówno token dostępu, jak i token odświeżania, które są szyfrowane i zapisywane w usłudze API Management |
5 | Po pobraniu tokenów, token dostępu jest dołączany przy użyciu zasad set-header jako nagłówek autoryzacji do wychodzącego żądania do API zaplecza |
6 | Odpowiedź jest zwracana do usługi API Management |
7 | Odpowiedź jest zwracana do klienta |
Powiązana zawartość
- Omówienie menedżera poświadczeń
- Konfigurowanie dostawców poświadczeń dla menedżera poświadczeń
- Konfigurowanie i używanie połączenia dla interfejsu API programu Microsoft Graph lub interfejsu API usługi GitHub
- Skonfiguruj wiele połączeń autoryzacji dla dostawcy
- Konfigurowanie połączenia na potrzeby dostępu delegowanego przez użytkownika