Aplikacje typu usługa-usługa

Ostrzeżenie

Ta zawartość dotyczy starszego punktu końcowego Azure AD w wersji 1.0. Użyj Platforma tożsamości Microsoft dla nowych projektów.

Aplikacje typu usługa-usługa mogą być demonem lub aplikacją serwera, która musi pobierać zasoby z internetowego interfejsu API. Istnieją dwa podrzędne scenariusze, które mają zastosowanie do tej sekcji:

• Demon, który musi wywołać internetowy interfejs API oparty na typie udzielania poświadczeń klienta OAuth 2.0

  W tym scenariuszu ważne jest zrozumienie kilku rzeczy. Po pierwsze interakcja użytkownika nie jest możliwa w przypadku aplikacji demona, która wymaga, aby aplikacja miała własną tożsamość. Przykładem aplikacji demona jest zadanie wsadowe lub usługa systemu operacyjnego uruchomiona w tle. Ten typ aplikacji żąda tokenu dostępu przy użyciu tożsamości aplikacji i przedstawienia identyfikatora aplikacji, poświadczeń (hasła lub certyfikatu) oraz identyfikatora URI aplikacji do Azure AD. Po pomyślnym uwierzytelnieniu demon odbiera token dostępu z Azure AD, który jest następnie używany do wywoływania internetowego interfejsu API.

• Aplikacja serwera (na przykład internetowy interfejs API), która musi wywoływać internetowy interfejs API oparty na specyfikacji OAuth 2.0 On-Behalf-Of draft

  W tym scenariuszu załóżmy, że użytkownik uwierzytelnił się w aplikacji natywnej, a ta aplikacja natywna musi wywołać internetowy interfejs API. Azure AD wystawia token dostępu JWT w celu wywołania internetowego interfejsu API. Jeśli internetowy interfejs API musi wywołać inny podrzędny internetowy interfejs API, może użyć przepływu w imieniu, aby delegować tożsamość użytkownika i uwierzytelniać się w interfejsie API sieci Web drugiej warstwy.

Diagram

Przepływ protokołu

Tożsamość aplikacji z przyznawaniem poświadczeń klienta OAuth 2.0

1. Najpierw aplikacja serwera musi uwierzytelniać się za pomocą Azure AD jako siebie bez interakcji z użytkownikami, takich jak okno dialogowe logowania interakcyjnego. Wysyła żądanie do punktu końcowego tokenu Azure AD, podając poświadczenia, identyfikator aplikacji i identyfikator URI identyfikatora aplikacji.
2. Azure AD uwierzytelnia aplikację i zwraca token dostępu JWT używany do wywoływania internetowego interfejsu API.
3. Za pośrednictwem protokołu HTTPS aplikacja internetowa używa zwróconego tokenu dostępu JWT, aby dodać ciąg JWT z oznaczeniem "Bearer" w nagłówku Authorization żądania do internetowego interfejsu API. Internetowy interfejs API weryfikuje następnie token JWT, a jeśli walidacja zakończy się pomyślnie, zwraca żądany zasób.

Tożsamość użytkownika delegowanego ze specyfikacją OAuth 2.0 w imieniu wersji roboczej

Opisany poniżej przepływ zakłada, że użytkownik został uwierzytelniony w innej aplikacji (takiej jak aplikacja natywna), a tożsamość użytkownika została użyta do uzyskania tokenu dostępu do interfejsu API sieci Web pierwszej warstwy.

1. Aplikacja natywna wysyła token dostępu do internetowego interfejsu API pierwszej warstwy.
2. Pierwszy warstwowy internetowy interfejs API wysyła żądanie do punktu końcowego tokenu Azure AD, podając identyfikator aplikacji i poświadczenia, a także token dostępu użytkownika. Ponadto żądanie jest wysyłane przy użyciu parametru on_behalf_of, który wskazuje, że internetowy interfejs API żąda nowych tokenów w celu wywołania podrzędnego internetowego interfejsu API w imieniu oryginalnego użytkownika.
3. Azure AD sprawdza, czy internetowy interfejs API pierwszej warstwy ma uprawnienia dostępu do interfejsu API sieci Web drugiej warstwy i weryfikuje żądanie, zwracając token dostępu JWT i token odświeżania JWT do internetowego interfejsu API pierwszej warstwy.
4. Za pośrednictwem protokołu HTTPS internetowy interfejs API pierwszej warstwy wywołuje następnie interfejs API sieci Web drugiej warstwy, dołączając ciąg tokenu w nagłówku Autoryzacja w żądaniu. Internetowy interfejs API pierwszej warstwy może nadal wywoływać interfejs API sieci Web warstwy drugiej, o ile token dostępu i tokeny odświeżania są prawidłowe.

Przykłady kodu

Zobacz przykłady kodu dla scenariuszy demona lub aplikacji serwera do internetowego interfejsu API: serwer lub aplikacja demona do internetowego interfejsu API

Rejestrowanie aplikacji

• Pojedyncza dzierżawa — zarówno w przypadku tożsamości aplikacji, jak i delegowanych przypadków tożsamości użytkownika demon lub aplikacja serwera musi być zarejestrowana w tym samym katalogu w Azure AD. Internetowy interfejs API można skonfigurować tak, aby uwidocznić zestaw uprawnień, które są używane do ograniczania dostępu demona lub serwera do jego zasobów. Jeśli jest używany delegowany typ tożsamości użytkownika, aplikacja serwera musi wybrać odpowiednie uprawnienia. Na stronie Uprawnienia interfejsu API dla rejestracji aplikacji po wybraniu pozycji Dodaj uprawnienie i wybraniu rodziny interfejsów API wybierz pozycję Uprawnienia delegowane, a następnie wybierz uprawnienia. Ten krok nie jest wymagany, jeśli jest używany typ tożsamości aplikacji.
• Wiele dzierżaw — najpierw demon lub aplikacja serwera jest skonfigurowana tak, aby wskazywała uprawnienia wymagane do funkcjonalności. Ta lista wymaganych uprawnień jest wyświetlana w oknie dialogowym, gdy użytkownik lub administrator w katalogu docelowym wyrazi zgodę na aplikację, która udostępnia ją swojej organizacji. Niektóre aplikacje wymagają tylko uprawnień na poziomie użytkownika, na które każdy użytkownik w organizacji może wyrazić zgodę. Inne aplikacje wymagają uprawnień na poziomie administratora, których użytkownik w organizacji nie może wyrazić na to zgody. Tylko administrator katalogu może wyrazić zgodę na aplikacje, które wymagają tego poziomu uprawnień. Gdy użytkownik lub administrator wyrazi zgodę, oba internetowe interfejsy API są zarejestrowane w katalogu.

Wygaśnięcie tokenu

Gdy pierwsza aplikacja używa kodu autoryzacji do pobrania tokenu dostępu JWT, otrzymuje również token odświeżania JWT. Po wygaśnięciu tokenu dostępu można użyć tokenu odświeżania do ponownego uwierzytelnienia użytkownika bez monitowania o poświadczenia. Ten token odświeżania jest następnie używany do uwierzytelniania użytkownika, co powoduje utworzenie nowego tokenu dostępu i tokenu odświeżania.

Następne kroki

• Dowiedz się więcej o innych typach aplikacji i scenariuszach
• Dowiedz się więcej o podstawach uwierzytelniania Azure AD