Internetowy interfejs API

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, które umożliwiają uwierzytelnianie jako aplikację i uzyskiwanie 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 ona wysłana za pośrednictwem protokołu aplikacji i nie zostanie podpisana przez usługę 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 zrealizować na dwa sposoby: OpenID Connect i przyznawanie kodu autoryzacji OAuth 2.0 za pomocą poufnego klienta. Aplikacja internetowa uzyskuje token dostępu dla użytkownika, który potwierdza interfejs API sieci Web, że użytkownik pomyślnie uwierzytelnił się w aplikacji internetowej i że aplikacja internetowa mogła uzyskać tożsamość użytkownika delegowanego 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.

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

Schemat

Przepływ protokołu

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

1. Użytkownik jest zalogowany do usługi 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ł uwierzytelniać się w internetowym interfejsie API i pobierać żądany zasób. Wysyła żądanie do punktu końcowego tokenów w usłudze Azure AD, podając poświadczenia, identyfikator aplikacji oraz identyfikator URI aplikacji webowego interfejsu API.
3. Usługa 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 autoryzacji żą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 za pomocą protokołu OpenID Connect

1. Użytkownik jest zalogowany do aplikacji internetowej przy użyciu usługi 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 nich ma uprawnienia na poziomie administratora, normalny użytkownik w katalogu nie będzie mógł wyrazić zgody. Ten proces wyrażania zgody dotyczy tylko aplikacji wielodomenowych, a nie aplikacji jednostanowych, ponieważ aplikacja będzie miała już niezbędne uprawnienia. Po zalogowaniu użytkownika aplikacja internetowa otrzymała token identyfikatora z informacjami o użytkowniku, a także kodem autoryzacji.
2. Korzystając z kodu autoryzacji wystawionego przez usługę Azure AD, aplikacja internetowa wysyła żądanie do punktu końcowego tokenu usługi 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 identyfikatora aplikacji dla internetowego interfejsu API).
3. Kod autoryzacji i informacje o aplikacji internetowej i internetowym interfejsie API są weryfikowane przez usługę Azure AD. Po pomyślnej weryfikacji usługa 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 autoryzacji żą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 z przyznawaniem kodu autoryzacji OAuth 2.0

1. Użytkownik jest już zalogowany do aplikacji internetowej, której mechanizm uwierzytelniania jest niezależny od usługi Azure AD.
2. Aplikacja internetowa wymaga kodu autoryzacji w celu uzyskania tokenu dostępu, dlatego wysyła żądanie za pośrednictwem przeglądarki do punktu końcowego autoryzacji usługi Azure AD, podając identyfikator aplikacji i identyfikator URI przekierowania dla aplikacji internetowej po pomyślnym uwierzytelnieniu. Użytkownik loguje się do usługi 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 nich ma uprawnienia na poziomie administratora, normalny użytkownik w katalogu nie będzie mógł wyrazić zgody. Ta zgoda ma zastosowanie zarówno do aplikacji pojedynczej, jak i wielodostępnej. W przypadku pojedynczej dzierżawy administrator może udzielić zgody w imieniu swoich użytkowników. Można to zrobić przy użyciu przycisku Grant Permissions w portalu Azure .
4. Po tym, jak użytkownik wyrazi zgodę, aplikacja internetowa otrzymuje kod autoryzacji, którego potrzebuje, aby uzyskać token dostępu.
5. Korzystając z kodu autoryzacji wystawionego przez usługę Azure AD, aplikacja internetowa wysyła żądanie do punktu końcowego tokenu usługi 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 identyfikatora aplikacji dla internetowego interfejsu API).
6. Kod autoryzacji i informacje o aplikacji internetowej i internetowym interfejsie API są weryfikowane przez usługę Azure AD. Po pomyślnej weryfikacji usługa 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 autoryzacji żą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.

Przykłady kodu

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

Rejestracja aplikacji

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

• Pojedyncza dzierżawa — zarówno w przypadku tożsamości aplikacji, jak i delegowanej tożsamości użytkownika, aplikacja webowa i interfejs API sieci Web muszą być zarejestrowane 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 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 witrynie Azure Portal. Ten krok nie jest wymagany, jeśli jest używany typ tożsamości aplikacji.
• Wielodostępność — Najpierw aplikacja internetowa jest skonfigurowana tak, aby wskazywała uprawnienia, które są wymagane do jej prawidłowego działania. 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 może wyrazić zgodę dowolny użytkownik w organizacji. Inne aplikacje wymagają uprawnień na poziomie administratora, na które 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ą rejestrowane w katalogu.

Wygaśnięcie tokenu

Gdy aplikacja internetowa używa 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 usługi Azure AD