Typy aplikacji w wersji 1.0

Usługa Azure Active Directory (Azure AD) obsługuje uwierzytelnianie dla różnych nowoczesnych architektur aplikacji, z których wszystkie są oparte na standardowych protokołach branżowych OAuth 2.0 lub OpenID Connect.

Na poniższym diagramie przedstawiono scenariusze i typy aplikacji oraz sposób dodawania różnych składników:

Oto pięć podstawowych scenariuszy aplikacji obsługiwanych przez usługę Azure AD:

• Aplikacja jednostronicowa (SPA): użytkownik musi zalogować się do aplikacji jednostronicowej zabezpieczonej przez usługę Azure AD.
• Przeglądarka internetowa do aplikacji internetowej: użytkownik musi zalogować się do aplikacji internetowej zabezpieczonej przez usługę Azure AD.
• Natywna aplikacja do web API: Natywna aplikacja działająca na telefonie, tablecie lub komputerze musi uwierzytelnić użytkownika, aby uzyskać zasoby z web API zabezpieczonego przez Azure AD.
• Aplikacja internetowa do interfejsu API: Aplikacja internetowa musi pobierać zasoby z interfejsu API zabezpieczonego usługą Azure AD.
• Daemon lub aplikacja serwera korzystająca z internetowego interfejsu API: aplikacja daemon lub serwerowa, która nie posiada interfejsu użytkownika webowego, musi pobierać zasoby z internetowego interfejsu API zabezpieczonego przez Azure AD.

Skorzystaj z linków, aby dowiedzieć się więcej o poszczególnych typach aplikacji i poznać scenariusze wysokiego poziomu przed rozpoczęciem pracy z kodem. Możesz również dowiedzieć się więcej o różnicach, które należy wiedzieć podczas pisania określonej aplikacji, która działa z punktem końcowym w wersji 1.0 lub punktem końcowym w wersji 2.0.

Możesz opracować dowolne aplikacje i scenariusze opisane tutaj przy użyciu różnych języków i platform. Są one wspierane przez kompletne przykłady kodu dostępne w przewodniku po przykładach kodu: przykłady kodu w wersji 1.0 według scenariusza i przykłady kodu w wersji 2.0 według scenariusza. Przykłady kodu można również pobrać bezpośrednio z odpowiednich repozytoriów przykładowych usługi GitHub.

Ponadto, jeśli aplikacja potrzebuje określonego elementu lub segmentu scenariusza kompleksowego, w większości przypadków funkcjonalność może być dodawana niezależnie. Jeśli na przykład masz aplikację natywną, która wywołuje internetowy interfejs API, możesz łatwo dodać aplikację internetową, która wywołuje również internetowy interfejs API.

Rejestracja aplikacji

Rejestrowanie aplikacji korzystającej z punktu końcowego usługi Azure AD w wersji 1.0

Każda aplikacja, która zleca uwierzytelnianie w usłudze Azure AD, musi być zarejestrowana w katalogu. Ten krok obejmuje informowanie usługi Azure AD o aplikacji, w tym adres URL, pod którym się znajduje, adres URL do wysyłania odpowiedzi po uwierzytelnieniu, identyfikator URI w celu zidentyfikowania aplikacji i nie tylko. Te informacje są wymagane z kilku kluczowych powodów:

• Usługa Azure AD musi komunikować się z aplikacją podczas obsługi logowania lub wymiany tokenów. Informacje przekazywane między usługą Azure AD a aplikacją obejmują następujące elementy:

  • Identyfikator URI aplikacji — identyfikator aplikacji. Ta wartość jest wysyłana do usługi Azure AD podczas uwierzytelniania, aby wskazać, dla której aplikacji obiekt wywołujący chce token. Ponadto ta wartość jest uwzględniana w tokenie, aby aplikacja wiedziała, że jest to zamierzony cel.
  • Adres URL odpowiedzi i URI przekierowania — w przypadku internetowego interfejsu API lub aplikacji internetowej, adres URL odpowiedzi określa miejsce, do którego usługa Azure AD prześle odpowiedź uwierzytelniającą, zawierającą token w przypadku, gdy uwierzytelnianie zakończyło się sukcesem. W przypadku aplikacji natywnej identyfikator URI przekierowania jest unikatowym identyfikatorem, do którego usługa Azure AD przekierowuje agenta użytkownika w żądaniu OAuth 2.0.
  • Identyfikator aplikacji — identyfikator aplikacji, która jest generowana przez usługę Azure AD po zarejestrowaniu aplikacji. Podczas żądania kodu autoryzacji lub tokenu identyfikator aplikacji i klucz są wysyłane do usługi Azure AD podczas uwierzytelniania.
  • Klucz — klucz, który jest wysyłany wraz z identyfikatorem aplikacji podczas uwierzytelniania w usłudze Azure AD w celu wywołania internetowego interfejsu API.

• Usługa Azure AD musi mieć pewność, że aplikacja ma wymagane uprawnienia dostępu do danych katalogu, innych aplikacji w organizacji itd.

Aby uzyskać szczegółowe informacje, dowiedz się, jak zarejestrować aplikację.

Aplikacje dla jednego najemcy i wielu najemców

Aprowizacja staje się jaśniejsza, gdy rozumiesz, że istnieją dwie kategorie aplikacji, które można opracowywać i integrować z usługą Azure AD:

• Aplikacja jedno-tenancyjna — aplikacja jedno-tenancyjna jest przeznaczona do użytku w ramach jednej organizacji. Są to zazwyczaj aplikacje biznesowe (LoB) napisane przez dewelopera przedsiębiorstwa. Aplikacja jednego dzierżawcy musi być dostępna tylko dla użytkowników w jednym katalogu, a w związku z tym musi być wdrożona tylko w jednym katalogu. Te aplikacje są zwykle rejestrowane przez dewelopera w organizacji.
• Aplikacja wielodostępna — aplikacja wielodostępna jest przeznaczona do użytku w wielu organizacjach, a nie tylko jednej organizacji. Są to zazwyczaj aplikacje typu SaaS (software-as-a-service) napisane przez niezależnych dostawców oprogramowania (ISV). Aplikacje wielodostępne należy aprowizować w każdym katalogu, w którym będą używane, co wymaga zgody użytkownika lub administratora na ich zarejestrowanie. Proces wyrażania zgody rozpoczyna się po zarejestrowaniu aplikacji w katalogu i udzieleniu jej dostępu do interfejsu API programu Graph lub innego internetowego interfejsu API. Gdy użytkownik lub administrator z innej organizacji zarejestruje się w celu korzystania z aplikacji, zostanie wyświetlone okno dialogowe z wyświetlonymi uprawnieniami wymaganymi przez aplikację. Użytkownik lub administrator może następnie wyrazić zgodę na aplikację, która daje aplikacji dostęp do określonych danych, a na koniec rejestruje aplikację w swoim katalogu. Aby uzyskać więcej informacji, zobacz Omówienie struktury wyrażania zgody.

Dodatkowe zagadnienia przy tworzeniu aplikacji jednostanowych i wielostanowych

Podczas tworzenia aplikacji wielodostępnej zamiast pojedynczej aplikacji dzierżawczej występują pewne dodatkowe kwestie. Jeśli na przykład udostępniasz aplikację użytkownikom w wielu katalogach, potrzebny jest mechanizm określania dzierżawy, w której się znajdują. Aplikacja z pojedynczą dzierżawą musi szukać użytkownika tylko w swoim katalogu, podczas gdy aplikacja z wieloma dzierżawami musi zidentyfikować określonego użytkownika ze wszystkich katalogów w usłudze Azure AD. Aby wykonać to zadanie, usługa Azure AD udostępnia wspólny punkt końcowy uwierzytelniania, w którym każda aplikacja wielodostępna może kierować żądania logowania zamiast punktu końcowego specyficznego dla dzierżawy. Ten punkt końcowy jest https://login.microsoftonline.com/common przeznaczony dla wszystkich katalogów w usłudze Azure AD, natomiast punkt końcowy specyficzny dla dzierżawy może mieć wartość https://login.microsoftonline.com/contoso.onmicrosoft.com. Typowy punkt końcowy jest szczególnie ważny, aby wziąć pod uwagę podczas tworzenia aplikacji, ponieważ wymagana jest logika niezbędna do obsługi wielu dzierżaw podczas logowania, wylogowania i walidacji tokenu.

Jeśli obecnie tworzysz pojedynczą aplikację dzierżawy, ale chcesz udostępnić ją wielu organizacjom, możesz łatwo wprowadzić zmiany w aplikacji i jej konfiguracji w usłudze Azure AD, aby umożliwić jej obsługę wielu dzierżaw. Ponadto usługa Azure AD używa tego samego klucza podpisywania dla wszystkich tokenów we wszystkich katalogach, niezależnie od tego, czy zapewniasz uwierzytelnianie w jednej dzierżawie, czy w aplikacji wielodzierżawowej.

Każdy scenariusz wymieniony w tym dokumencie zawiera podsekcję opisującą wymagania dotyczące wdrożenia. Aby uzyskać bardziej szczegółowe informacje na temat konfigurowania aplikacji w usłudze Azure AD oraz różnic między aplikacjami jedno- i wielodziedżawowymi, przeczytaj Integrowanie aplikacji z usługą Azure Active Directory. Kontynuuj czytanie, aby zrozumieć typowe scenariusze aplikacji w usłudze Azure AD.

Dalsze kroki

• Dowiedz się więcej o innych podstawach uwierzytelniania usługi Azure AD