Interfejs API sieci Web

Ostrzeżenie

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

Aplikacje internetowego interfejsu API to aplikacje internetowe, które muszą pobierać zasoby z internetowego interfejsu API. W tym scenariuszu istnieją dwa typy tożsamości, których aplikacja internetowa może używać do uwierzytelniania i wywoływania internetowego interfejsu API:

• Tożsamość aplikacji — w tym scenariuszu używane są poświadczenia klienta OAuth 2.0 do uwierzytelniania jako aplikacji i uzyskiwania dostępu do internetowego interfejsu API. W przypadku korzystania z tożsamości aplikacji internetowy interfejs API może wykryć tylko, że aplikacja internetowa wywołuje ją, ponieważ internetowy interfejs API nie otrzymuje żadnych informacji o użytkowniku. Jeśli aplikacja otrzyma informacje o użytkowniku, zostanie wysłana za pośrednictwem protokołu aplikacji i nie zostanie podpisana przez Azure AD. Internetowy interfejs API ufa uwierzytelnieniu użytkownika przez aplikację internetową. Z tego powodu ten wzorzec jest nazywany zaufanym podsystemem.
• Tożsamość użytkownika delegowanego — ten scenariusz można wykonać na dwa sposoby: OpenID Connect i kod autoryzacji OAuth 2.0 z poufnym klientem. Aplikacja internetowa uzyskuje token dostępu dla użytkownika, który potwierdza internetowy interfejs API, że użytkownik pomyślnie uwierzytelnił się w aplikacji internetowej i że aplikacja internetowa mogła uzyskać delegowanej tożsamości użytkownika w celu wywołania internetowego interfejsu API. Ten token dostępu jest wysyłany w żądaniu do internetowego interfejsu API, który autoryzuje użytkownika i zwraca żądany zasób.

Zarówno tożsamość aplikacji, jak i delegowane typy tożsamości użytkownika zostały omówione w poniższym przepływie. Kluczową różnicą między nimi jest to, że tożsamość użytkownika delegowanego musi najpierw uzyskać kod autoryzacji, zanim użytkownik będzie mógł się zalogować i uzyskać dostęp do internetowego interfejsu API.

Diagram

Przepływ protokołu

Tożsamość aplikacji z udzielaniem poświadczeń klienta protokołu OAuth 2.0

1. Użytkownik jest zalogowany do Azure AD w aplikacji internetowej (zobacz sekcję Aplikacje internetowe, aby uzyskać więcej informacji).
2. Aplikacja internetowa musi uzyskać token dostępu, aby mógł uwierzytelnić się w internetowym interfejsie API i pobrać żądany zasób. Wysyła żądanie do punktu końcowego tokenu Azure AD, podając identyfikator URI poświadczeń, identyfikator aplikacji i identyfikator aplikacji internetowego interfejsu API.
3. Azure AD uwierzytelnia aplikację i zwraca token dostępu JWT używany do wywoływania internetowego interfejsu API.
4. 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 Autoryzacja żądania do internetowego interfejsu API. Internetowy interfejs API następnie weryfikuje token JWT, a jeśli walidacja zakończy się pomyślnie, zwraca żądany zasób.

Tożsamość użytkownika delegowanego za pomocą interfejsu OpenID Connect

1. Użytkownik jest zalogowany do aplikacji internetowej przy użyciu Azure AD (zobacz sekcję Przeglądarka internetowa do aplikacji internetowej powyżej). Jeśli użytkownik aplikacji internetowej nie wyraził jeszcze zgody na zezwolenie aplikacji internetowej na wywołanie internetowego interfejsu API w jego imieniu, użytkownik będzie musiał wyrazić zgodę. Aplikacja wyświetli wymagane uprawnienia, a jeśli którykolwiek z tych uprawnień jest na poziomie administratora, normalny użytkownik w katalogu nie będzie mógł wyrazić zgody. Ten proces zgody dotyczy tylko aplikacji wielodostępnych, a nie aplikacji z jedną dzierżawą, ponieważ aplikacja będzie już mieć niezbędne uprawnienia. Po zalogowaniu się użytkownik aplikacja internetowa otrzymała token identyfikatora z informacjami o użytkowniku, a także kodem autoryzacji.
2. Przy użyciu kodu autoryzacji wydanego przez Azure AD aplikacja internetowa wysyła żądanie do punktu końcowego tokenu Azure AD, który zawiera kod autoryzacji, szczegółowe informacje o aplikacji klienckiej (identyfikator aplikacji i identyfikator URI przekierowania) oraz żądany zasób (identyfikator URI aplikacji dla internetowego interfejsu API).
3. Kod autoryzacji i informacje o aplikacji internetowej i internetowym interfejsie API są weryfikowane przez Azure AD. Po pomyślnej weryfikacji Azure AD zwraca dwa tokeny: token dostępu JWT i token odświeżania JWT.
4. 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 Autoryzacja żądania do internetowego interfejsu API. Internetowy interfejs API następnie weryfikuje token JWT, a jeśli walidacja zakończy się pomyślnie, zwraca żądany zasób.

Tożsamość użytkownika delegowanego z udzielaniem kodu autoryzacji OAuth 2.0

1. Użytkownik jest już zalogowany do aplikacji internetowej, której mechanizm uwierzytelniania jest niezależny od Azure AD.
2. Aplikacja internetowa wymaga kodu autoryzacji w celu uzyskania tokenu dostępu, dlatego wysyła żądanie za pośrednictwem przeglądarki w celu Azure AD punktu końcowego autoryzacji, podając identyfikator aplikacji i identyfikator URI przekierowania dla aplikacji internetowej po pomyślnym uwierzytelnieniu. Użytkownik loguje się do Azure AD.
3. Jeśli użytkownik aplikacji internetowej nie wyraził jeszcze zgody na zezwolenie aplikacji internetowej na wywołanie internetowego interfejsu API w jego imieniu, użytkownik będzie musiał wyrazić zgodę. Aplikacja wyświetli wymagane uprawnienia, a jeśli którykolwiek z tych uprawnień jest na poziomie administratora, normalny użytkownik w katalogu nie będzie mógł wyrazić zgody. Ta zgoda dotyczy zarówno aplikacji pojedynczej, jak i wielodostępnej. W przypadku pojedynczej dzierżawy administrator może wyrazić zgodę administratora na zgodę w imieniu swoich użytkowników. Można to zrobić za pomocą Grant Permissions przycisku w Azure Portal.
4. Gdy użytkownik wyrazi zgodę, aplikacja internetowa otrzyma kod autoryzacji, który musi uzyskać token dostępu.
5. Przy użyciu kodu autoryzacji wydanego przez Azure AD aplikacja internetowa wysyła żądanie do punktu końcowego tokenu Azure AD, który zawiera kod autoryzacji, szczegółowe informacje o aplikacji klienckiej (identyfikator aplikacji i identyfikator URI przekierowania) oraz żądany zasób (identyfikator URI aplikacji dla internetowego interfejsu API).
6. Kod autoryzacji i informacje o aplikacji internetowej i internetowym interfejsie API są weryfikowane przez Azure AD. Po pomyślnej weryfikacji Azure AD zwraca dwa tokeny: token dostępu JWT i token odświeżania JWT.
7. 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 Autoryzacja żądania do internetowego interfejsu API. Internetowy interfejs API następnie weryfikuje token JWT, a jeśli walidacja zakończy się pomyślnie, zwraca żądany zasób.

Przykłady kodu

Zobacz przykłady kodu dla scenariuszy interfejsu API sieci Web dla aplikacji internetowej. Sprawdź często — często dodawane są nowe próbki. Aplikacja internetowa do internetowego interfejsu API.

Rejestrowanie aplikacji

Aby zarejestrować aplikację w punkcie końcowym Azure AD w wersji 1.0, zobacz Rejestrowanie aplikacji.

• Pojedyncza dzierżawa — zarówno w przypadku tożsamości aplikacji, jak i delegowanych przypadków tożsamości użytkownika aplikacja internetowa i internetowy interfejs API muszą być zarejestrowane w tym samym katalogu w Azure AD. Internetowy interfejs API można skonfigurować tak, aby uwidaczniać zestaw uprawnień, które są używane do ograniczania dostępu aplikacji internetowej do jej zasobów. Jeśli używany jest delegowany typ tożsamości użytkownika, aplikacja internetowa musi wybrać odpowiednie uprawnienia z menu rozwijanego Uprawnienia do innych aplikacji w Azure Portal. Ten krok nie jest wymagany, jeśli używany jest typ tożsamości aplikacji.
• Wiele dzierżaw — najpierw aplikacja internetowa 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, do których 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ć zgody. Tylko administrator katalogu może wyrazić zgodę na aplikacje, które wymagają tego poziomu uprawnień. Gdy użytkownik lub administrator wyrazi zgodę, aplikacja internetowa i internetowy interfejs API są zarejestrowane w swoim katalogu.

Wygaśnięcie tokenu

Gdy aplikacja internetowa używa swojego kodu autoryzacji do uzyskania tokenu dostępu JWT, otrzymuje również token odświeżania JWT. Po wygaśnięciu tokenu dostępu token odświeżania może służyć do ponownego uwierzytelnienia użytkownika bez konieczności ponownego logowania się. 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