Udostępnij za pośrednictwem

Aplikacje natywne

  • Artykuł

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 natywne to aplikacje wywołujące internetowy interfejs API w imieniu użytkownika. Ten scenariusz jest oparty na typie udzielania kodu autoryzacji OAuth 2.0 z klientem publicznym, zgodnie z opisem w sekcji 4.1 specyfikacji OAuth 2.0. Aplikacja natywna uzyskuje token dostępu dla użytkownika przy użyciu protokołu OAuth 2.0. Ten token dostępu jest następnie wysyłany w żądaniu do internetowego interfejsu API, który autoryzuje użytkownika i zwraca żądany zasób.

Diagram

Diagram natywnej aplikacji do internetowego interfejsu API

Przepływ protokołu

Jeśli używasz bibliotek uwierzytelniania usługi AD, większość opisanych poniżej szczegółów protokołu jest obsługiwana, takich jak wyskakujące okienko przeglądarki, buforowanie tokenów i obsługa tokenów odświeżania.

  1. Przy użyciu wyskakującego okienka przeglądarki aplikacja natywna wysyła żądanie do punktu końcowego autoryzacji w Azure AD. To żądanie zawiera identyfikator aplikacji i identyfikator URI przekierowania aplikacji natywnej, jak pokazano w Azure Portal, oraz identyfikator URI identyfikatora aplikacji dla internetowego interfejsu API. Jeśli użytkownik jeszcze się nie zalogował, zostanie wyświetlony monit o ponowne zalogowanie się
  2. Azure AD uwierzytelnia użytkownika. Jeśli jest to aplikacja wielodostępna i wymagana jest zgoda na korzystanie z aplikacji, użytkownik będzie musiał wyrazić zgodę, jeśli jeszcze tego nie zrobiono. Po udzieleniu zgody i pomyślnym uwierzytelnieniu Azure AD wystawia odpowiedź kodu autoryzacji z powrotem do identyfikatora URI przekierowania aplikacji klienckiej.
  3. Gdy Azure AD wystawia odpowiedź kodu autoryzacji z powrotem do identyfikatora URI przekierowania, aplikacja kliencka zatrzymuje interakcję przeglądarki i wyodrębnia kod autoryzacji z odpowiedzi. Korzystając z tego kodu autoryzacji, aplikacja kliencka 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 identyfikatora aplikacji dla internetowego interfejsu API).
  4. Kod autoryzacji i informacje o aplikacji klienckiej 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. Ponadto Azure AD zwraca podstawowe informacje o użytkowniku, takie jak nazwa wyświetlana i identyfikator dzierżawy.
  5. Za pośrednictwem protokołu HTTPS aplikacja kliencka używa zwróconego tokenu dostępu JWT w celu dodania ciągu JWT z oznaczeniem "Bearer" w nagłówku Autoryzacja żą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.
  6. Po wygaśnięciu tokenu dostępu aplikacja kliencka otrzyma błąd wskazujący, że użytkownik musi ponownie się uwierzytelnić. Jeśli aplikacja ma prawidłowy token odświeżania, może służyć do uzyskania nowego tokenu dostępu bez monitowania użytkownika o ponowne zalogowanie. Jeśli token odświeżania wygaśnie, aplikacja będzie musiała interaktywnie uwierzytelnić użytkownika po raz kolejny.

Uwaga

Token odświeżania wystawiony przez Azure AD może służyć do uzyskiwania dostępu do wielu zasobów. Jeśli na przykład masz aplikację kliencką, która ma uprawnienia do wywoływania dwóch internetowych interfejsów API, token odświeżania może służyć do uzyskiwania tokenu dostępu do innego internetowego interfejsu API.

Przykłady kodu

Zobacz przykłady kodu dla scenariuszy interfejsu API aplikacji natywnej do sieci Web. I często sprawdzamy często — często dodajemy nowe próbki. Natywna aplikacja 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 aplikacja natywna, jak 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 natywnej do jej zasobów. Następnie aplikacja kliencka wybiera odpowiednie uprawnienia z menu rozwijanego "Uprawnienia do innych aplikacji" w Azure Portal.
  • Wielodostępna — najpierw aplikacja natywna tylko kiedykolwiek zarejestrowana w katalogu dewelopera lub wydawcy. Po drugie aplikacja natywna jest skonfigurowana tak, aby wskazywała uprawnienia wymagane do 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 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ę, w katalogu jest zarejestrowany tylko internetowy interfejs API.

Wygaśnięcie tokenu

Gdy aplikacja natywna 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 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