Typy aplikacji w wersji 1.0

  • 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.

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

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

Typy aplikacji i scenariusze

Są to pięć podstawowych scenariuszy aplikacji obsługiwanych przez Azure AD:

Skorzystaj z linków, aby dowiedzieć się więcej na temat poszczególnych typów aplikacji i zapoznać się ze scenariuszami 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 współpracuje z punktem końcowym w wersji 1.0 lub punktem końcowym w wersji 2.0.

Uwaga

Punkt końcowy w wersji 2.0 nie obsługuje wszystkich scenariuszy i funkcji Azure AD. Aby określić, czy należy używać punktu końcowego w wersji 2.0, przeczytaj o ograniczeniach wersji 2.0.

Możesz opracować dowolne aplikacje i scenariusze opisane tutaj przy użyciu różnych języków i platform. Wszystkie są 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 wymaga określonego elementu lub segmentu scenariusza kompleksowego, w większości przypadków funkcjonalność można dodać 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 również wywołuje internetowy interfejs API.

Rejestrowanie aplikacji

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

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

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

    • Identyfikator URI identyfikatora aplikacji — identyfikator aplikacji. Ta wartość jest wysyłana do Azure AD podczas uwierzytelniania, aby wskazać, dla której aplikacji obiekt wywołujący chce uzyskać token. Ponadto ta wartość jest uwzględniana w tokenie, aby aplikacja wiedziała, że była to zamierzony element docelowy.
    • Adres URL odpowiedzi i identyfikator URI przekierowania — w przypadku internetowego interfejsu API lub aplikacji internetowej adres URL odpowiedzi to lokalizacja, w której Azure AD wyśle odpowiedź uwierzytelniania, w tym token, jeśli uwierzytelnianie zakończyło się pomyślnie. W przypadku aplikacji natywnej identyfikator URI przekierowania jest unikatowym identyfikatorem, do którego Azure AD przekierowuje agenta użytkownika w żądaniu OAuth 2.0.
    • Identyfikator aplikacji — identyfikator aplikacji, który jest generowany przez Azure AD po zarejestrowaniu aplikacji. Podczas żądania kodu autoryzacji lub tokenu identyfikator aplikacji i klucz są wysyłane do Azure AD podczas uwierzytelniania.
    • Klucz — klucz, który jest wysyłany wraz z identyfikatorem aplikacji podczas uwierzytelniania do Azure AD w celu wywołania internetowego interfejsu API.

  • Azure AD musi upewnić się, ż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 z jedną dzierżawą i wieloma dzierżawami

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

  • Aplikacja z jedną dzierżawą — aplikacja z jedną dzierżawą jest przeznaczona do użytku w jednej organizacji. Są to zazwyczaj aplikacje biznesowe (LoB) napisane przez dewelopera przedsiębiorstwa. Dostęp do pojedynczej aplikacji dzierżawy musi uzyskiwać tylko użytkownicy w jednym katalogu. W związku z tym należy aprowizować ją tylko w jednym katalogu. Te aplikacje są zwykle rejestrowane przez dewelopera w organizacji.
  • Aplikacja z wieloma dzierżawami — aplikacja z wieloma dzierżawami jest przeznaczona do użytku w wielu organizacjach, a nie tylko w 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 zapewnia 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 dotyczące tworzenia aplikacji z jedną dzierżawą lub wieloma dzierżawami

Podczas tworzenia aplikacji wielodostępnej zamiast pojedynczej aplikacji dzierżawczej pojawiają się dodatkowe zagadnienia. 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 jedną dzierżawą musi szukać tylko własnego katalogu dla użytkownika, podczas gdy aplikacja z wieloma dzierżawami musi zidentyfikować określonego użytkownika ze wszystkich katalogów w Azure AD. Aby wykonać to zadanie, Azure AD udostępnia wspólny punkt końcowy uwierzytelniania, w którym każda aplikacja z wieloma dzierżawami 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 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ż potrzebna jest logika niezbędna do obsługi wielu dzierżaw podczas logowania, wylogowania i weryfikacji tokenu.

Jeśli obecnie tworzysz aplikację z jedną dzierżawą, ale chcesz udostępnić ją wielu organizacjom, możesz łatwo wprowadzić zmiany w aplikacji i jej konfiguracji w Azure AD, aby umożliwić jej obsługę wielu dzierżaw. Ponadto 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 wielodostępnej.

Każdy scenariusz wymieniony w tym dokumencie zawiera podsekcję opisjącą wymagania dotyczące aprowizacji. Aby uzyskać bardziej szczegółowe informacje na temat aprowizacji aplikacji w Azure AD i różnic między aplikacjami z jedną i wieloma dzierżawami, zobacz Integrowanie aplikacji z usługą Azure Active Directory, aby uzyskać więcej informacji. Kontynuuj czytanie, aby zrozumieć typowe scenariusze aplikacji w Azure AD.

Następne kroki