Aplikacje natywne

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.

Schemat

Przepływ protokołu

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

1. Korzystając z wyskakującego okienka przeglądarki, aplikacja natywna wysyła żądanie do punktu końcowego autoryzacji w usłudze Azure AD. To żądanie zawiera identyfikator aplikacji i identyfikator URI przekierowania aplikacji natywnej, jak pokazano w portalu Azure, oraz identyfikator URI aplikacji dla internetowego interfejsu API. Jeśli użytkownik jeszcze się nie zalogował, zostanie wyświetlony monit o ponowne zalogowanie się
2. Usługa Azure AD uwierzytelnia użytkownika. Jeśli jest to aplikacja z wieloma dzierżawami i zgoda jest wymagana do korzystania z aplikacji, użytkownik będzie musiał ją wyrazić, jeśli jeszcze tego nie zrobił. Po udzieleniu zgody i pomyślnym uwierzytelnieniu usługa Azure AD wysyła z powrotem odpowiedź z kodem autoryzacyjnym na identyfikator URI przekierowania aplikacji klienckiej.
3. Gdy usługa Azure AD wystawia odpowiedź kodu autoryzacji z powrotem na identyfikator 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 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).
4. Kod autoryzacji i informacje o aplikacji klienckiej 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. Ponadto usługa 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, aby dodać ciąg JWT z oznaczeniem "Bearer" w nagłówku autoryzacji żądania do interfejsu API sieciowego. 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.

Przykłady kodu

Zobacz przykłady kodu dla scenariuszy interfejsu API aplikacji natywnej do sieci Web. I często sprawdzamy ponownie — często dodajemy nowe przykłady. Natywna aplikacja do interfejsu API sieci web.

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 aplikacja natywna, jak i internetowy interfejs API muszą być zarejestrowane w tym samym katalogu w usłudze Azure AD. Internetowy interfejs API można skonfigurować tak, aby uwidocznić 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 witrynie Azure Portal.
• W środowisku wielu dzierżaw — aplikacja natywna była zarejestrowana tylko w katalogu dewelopera lub wydawcy. Po drugie, aplikacja natywna jest skonfigurowana tak, aby wskazywała uprawnienia, których wymaga 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 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ę, tylko internetowy interfejs API jest zarejestrowany w katalogu.

Wygaśnięcie tokenu

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