Sdílet prostřednictvím


Typy aplikací ve verzi 1.0

Upozornění

Tento obsah je určený pro starší koncový bod Azure AD verze 1.0. Pro nové projekty použijte Microsoft identity platform.

Azure Active Directory (Azure AD) podporuje ověřování pro celou řadu moderních architektur aplikací, všechny založené na standardních protokolech OAuth 2.0 nebo OpenID Connect.

Následující diagram znázorňuje scénáře a typy aplikací a způsob přidání různých komponent:

Typy a scénáře aplikací

Azure AD podporuje pět primárních scénářů aplikací:

Než začnete pracovat s kódem, podívejte se na odkazy, abyste se dozvěděli více o jednotlivých typech aplikací a porozuměli scénářům vysoké úrovně. Můžete se také dozvědět o rozdílech, které potřebujete znát při psaní konkrétní aplikace, která funguje s koncovým bodem verze 1.0 nebo koncovým bodem verze 2.0.

Poznámka

Koncový bod verze 2.0 nepodporuje všechny Azure AD scénáře a funkce. Pokud chcete zjistit, jestli byste měli používat koncový bod verze 2.0, přečtěte si o omezeních verze 2.0.

V různých jazycích a platformách můžete vyvíjet libovolné aplikace a scénáře popsané tady. Všechny se opírají o kompletní ukázky kódu, které jsou k dispozici v průvodci ukázkami kódu: ukázky kódu verze 1.0 podle scénáře a ukázky kódu verze 2.0 podle scénáře. Ukázky kódu si také můžete stáhnout přímo z odpovídajících ukázkových úložišť GitHubu.

Kromě toho platí, že pokud vaše aplikace potřebuje konkrétní část nebo segment komplexního scénáře, ve většině případů je možné tyto funkce přidat nezávisle. Pokud máte například nativní aplikaci, která volá webové rozhraní API, můžete snadno přidat webovou aplikaci, která také volá webové rozhraní API.

Registrace aplikace

Registrace aplikace, která používá koncový bod Azure AD v1.0

Každá aplikace, která zajišťuje ověřování na Azure AD, musí být zaregistrovaná v adresáři. Tento krok zahrnuje oznámení Azure AD o vaší aplikaci, včetně adresy URL, kde se nachází, adresy URL pro odesílání odpovědí po ověření, identifikátoru URI pro identifikaci vaší aplikace a dalších. Tyto informace jsou vyžadovány z několika klíčových důvodů:

  • Azure AD musí komunikovat s aplikací při zpracování přihlašování nebo výměny tokenů. Informace předávané mezi Azure AD a aplikací zahrnují následující:

    • Identifikátor URI ID aplikace – identifikátor aplikace. Tato hodnota se během ověřování odešle do Azure AD, aby bylo možné určit, pro kterou aplikaci volající chce token. Tato hodnota je navíc zahrnuta v tokenu, aby aplikace věděla, že se jedná o zamýšlený cíl.
    • Adresa URL odpovědi a identifikátor URI přesměrování – u webového rozhraní API nebo webové aplikace je adresa URL odpovědi umístění, kam Azure AD odešle ověřovací odpověď, včetně tokenu, pokud bylo ověření úspěšné. Identifikátor URI přesměrování pro nativní aplikaci je jedinečný identifikátor, na který Azure AD přesměruje uživatelského agenta v požadavku OAuth 2.0.
    • ID aplikace – ID aplikace, které je generováno Azure AD při registraci aplikace. Při žádosti o autorizační kód nebo token se ID aplikace a klíč během ověřování odesílají do Azure AD.
    • Klíč – klíč, který se odešle spolu s ID aplikace při ověřování do Azure AD volání webového rozhraní API.
  • Azure AD musí zajistit, aby aplikace získala požadovaná oprávnění pro přístup k vašim datům adresáře, dalším aplikacím ve vaší organizaci atd.

Podrobnosti najdete v článku o registraci aplikace.

Aplikace s jedním a více tenanty

Zřizování je jasnější, když pochopíte, že existují dvě kategorie aplikací, které je možné vyvíjet a integrovat s Azure AD:

  • Aplikace s jedním tenantem – Aplikace s jedním tenantem je určená pro použití v jedné organizaci. Obvykle se jedná o obchodní aplikace napsané podnikovým vývojářem. Aplikace jednoho tenanta musí být přístupná pouze uživatelům v jednom adresáři, a proto musí být zřízena pouze v jednom adresáři. Tyto aplikace jsou obvykle registrovány vývojářem v organizaci.
  • Aplikace s více tenanty – Aplikace s více tenanty je určená pro použití v mnoha organizacích, ne jenom v jedné organizaci. Obvykle se jedná o aplikace SaaS (software-as-a-service) napsané nezávislým dodavatelem softwaru (ISV). Aplikace s více tenanty musí být zřízené v každém adresáři, kde se budou používat, což vyžaduje souhlas uživatele nebo správce, aby je mohli zaregistrovat. Tento proces souhlasu se spustí, když je aplikace zaregistrovaná v adresáři a má přístup k Graph API nebo třeba jinému webovému rozhraní API. Když se uživatel nebo správce z jiné organizace zaregistruje k používání aplikace, zobrazí se mu dialogové okno s oprávněními, která aplikace vyžaduje. Uživatel nebo správce pak může s aplikací vyjádřit souhlas, který aplikaci poskytne přístup k datům a nakonec aplikaci zaregistruje ve svém adresáři. Další informace najdete v tématu Přehled architektury pro vyjádření souhlasu.

Další aspekty při vývoji aplikací s jedním nebo více tenanty

Při vývoji aplikace s více tenanty místo aplikace s jedním tenantem je potřeba vzít v úvahu několik dalších aspektů. Pokud například zpřístupňujete aplikaci uživatelům ve více adresářích, potřebujete mechanismus, který určí, ve kterém tenantovi se nachází. Jedna aplikace tenanta musí uživatele vyhledat pouze ve svém vlastním adresáři, zatímco aplikace s více tenanty musí identifikovat konkrétního uživatele ze všech adresářů v Azure AD. Aby bylo možné tuto úlohu provést, Azure AD poskytuje společný koncový bod ověřování, ve kterém může žádosti o přihlášení směrovat jakákoli aplikace s více tenanty místo koncového bodu specifického pro tenanta. Tento koncový bod je https://login.microsoftonline.com/common pro všechny adresáře v Azure AD, zatímco koncový bod specifický pro tenanta může být https://login.microsoftonline.com/contoso.onmicrosoft.com. Při vývoji aplikace je obzvláště důležité zvážit běžný koncový bod, protože budete potřebovat potřebnou logiku pro zpracování více tenantů během přihlašování, odhlašování a ověřování tokenů.

Pokud aktuálně vyvíjíte aplikaci s jedním tenantem, ale chcete ji zpřístupnit mnoha organizacím, můžete snadno provést změny aplikace a její konfigurace v Azure AD, aby byla schopná používat více tenantů. Kromě toho Azure AD používá stejný podpisový klíč pro všechny tokeny ve všech adresářích bez ohledu na to, jestli poskytujete ověřování v jednom tenantovi nebo v aplikaci s více tenanty.

Každý scénář uvedený v tomto dokumentu obsahuje dílčí část, která popisuje požadavky na zřizování. Podrobnější informace o zřizování aplikace v Azure AD a rozdílech mezi aplikacemi s jedním a více tenanty najdete v tématu Integrace aplikací se službou Azure Active Directory. Pokračujte ve čtení a seznamte se s běžnými scénáři aplikací v Azure AD.

Další kroky