Udostępnij przez

Połączenia OAuth 2.0 w menedżerze poświadczeń — szczegóły procesu i przepływy

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łączając przepływ zgody dla dostawcy i konfigurując co najmniej jedno połączenie 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.

Diagram przedstawiający przepływ procesów tworzenia poświadczeń.

Krok Opis
1 Klient wysyła żądanie utworzenia dostawcy poświadczeń.
2 Dostawca poświadczeń jest tworzony, a odpowiedź jest wysył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 używany po przekierowaniu 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 OAuth 2.0 dostawcy poświadczeń.
8 Po zatwierdzeniu zgody przeglądarka zostanie przekierowana przy użyciu kodu autoryzacji do adresu URL przekierowania skonfigurowanego u dostawcy poświadczeń.
9 Usługa API Management 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 modułu dostawcy poświadczeń, menedżer poświadczeń tworzy w tle magazyn poświadczeń, który jest 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ń. Jeśli na przykład chcesz skonfigurować identyfikator Entra firmy Microsoft do używania obu typów dotacji, potrzebne są dwie konfiguracje dostawcy 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

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 używa 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łączeń 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ęść runtime wymaga skonfigurowania zaplecza interfejsu API OAuth 2.0 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 nastąpi wywołanie interfejsu API na zapleczu.

Diagram przedstawiający przepływ procesu pobierania tokenu w czasie wykonywania.

Krok Opis
1 Klient wysyła żądanie do wystąpienia Zarządzania API.
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 jako nagłówek autoryzacji do wychodzącego żądania do interfejsu API zaplecza przy użyciu polityki set-header.
6 Odpowiedź jest zwracana do usługi API Management.
7 Odpowiedź jest zwracana do klienta.

Powiązana zawartość

  • Last updated on