Sdílet prostřednictvím

Nativní aplikace

  • Článek

Upozornění

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

Nativní aplikace jsou aplikace, které jménem uživatele volají webové rozhraní API. Tento scénář je založený na typu udělení autorizačního kódu OAuth 2.0 s veřejným klientem, jak je popsáno v části 4.1 specifikace OAuth 2.0. Nativní aplikace získá přístupový token pro uživatele pomocí protokolu OAuth 2.0. Tento přístupový token se pak odešle v požadavku do webového rozhraní API, které autorizuje uživatele a vrátí požadovaný prostředek.

Diagram

Diagram nativního rozhraní API pro aplikaci na web

Tok protokolu

Pokud používáte knihovny ověřování SLUŽBY AD, většina podrobností o protokolu popsaných níže je zpracována za vás, například automaticky otevírané okno prohlížeče, ukládání tokenů do mezipaměti a zpracování obnovovacích tokenů.

  1. Pomocí automaticky otevíraných oken prohlížeče vytvoří nativní aplikace požadavek na koncový bod autorizace v Azure AD. Tento požadavek zahrnuje ID aplikace a identifikátor URI přesměrování nativní aplikace, jak je znázorněno v Azure Portal, a identifikátor URI ID aplikace pro webové rozhraní API. Pokud se uživatel ještě nepřihlásil, zobrazí se mu výzva k opětovnému přihlášení.
  2. Azure AD uživatele ověří. Pokud se jedná o aplikaci s více tenanty a vyžaduje se souhlas s používáním aplikace, bude uživatel muset vyjádřit souhlas, pokud to ještě neudělal. Po udělení souhlasu a po úspěšném ověření vydá Azure AD odpověď autorizačního kódu zpět na identifikátor URI přesměrování klientské aplikace.
  3. Když Azure AD vydá odpověď autorizačního kódu zpět na identifikátor URI přesměrování, klientská aplikace zastaví interakci prohlížeče a extrahuje autorizační kód z odpovědi. Pomocí tohoto autorizačního kódu klientská aplikace odešle požadavek na koncový bod tokenu Azure AD, který obsahuje autorizační kód, podrobnosti o klientské aplikaci (ID aplikace a identifikátor URI přesměrování) a požadovaný prostředek (identifikátor URI ID aplikace pro webové rozhraní API).
  4. Autorizační kód a informace o klientské aplikaci a webovém rozhraní API ověřuje Azure AD. Po úspěšném ověření vrátí Azure AD dva tokeny: přístupový token JWT a obnovovací token JWT. Kromě toho Azure AD vrátí základní informace o uživateli, například jeho zobrazované jméno a ID tenanta.
  5. Přes HTTPS klientská aplikace pomocí vráceného přístupového tokenu JWT přidá řetězec JWT s označením Nosný do autorizační hlavičky požadavku do webového rozhraní API. Webové rozhraní API pak ověří token JWT, a pokud je ověření úspěšné, vrátí požadovaný prostředek.
  6. Po vypršení platnosti přístupového tokenu se klientské aplikaci zobrazí chyba, která značí, že uživatel se musí znovu ověřit. Pokud má aplikace platný obnovovací token, můžete ho použít k získání nového přístupového tokenu bez výzvy k opětovnému přihlášení uživatele. Pokud platnost obnovovacího tokenu vyprší, bude aplikace muset znovu interaktivně ověřit uživatele.

Poznámka

Obnovovací token vydaný Azure AD je možné použít pro přístup k více prostředkům. Pokud máte například klientskou aplikaci, která má oprávnění volat dvě webová rozhraní API, můžete pomocí obnovovacího tokenu získat přístupový token i do jiného webového rozhraní API.

Ukázky kódů

Projděte si ukázky kódu pro scénáře nativního rozhraní API pro aplikace na web. A často se vracávejte – často přidáváme nové vzorky. Nativní rozhraní API z aplikace na web

Registrace aplikace

Informace o registraci aplikace pomocí koncového bodu Azure AD v1.0 najdete v tématu Registrace aplikace.

  • Jeden tenant – nativní aplikace i webové rozhraní API musí být zaregistrované ve stejném adresáři v Azure AD. Webové rozhraní API je možné nakonfigurovat tak, aby zpřístupnilo sadu oprávnění, která se používají k omezení přístupu nativní aplikace k jejím prostředkům. Klientská aplikace pak vybere požadovaná oprávnění z rozevírací nabídky Oprávnění k jiným aplikacím v Azure Portal.
  • Více tenantů – zaprvé, nativní aplikace, která byla zaregistrovaná pouze v adresáři vývojáře nebo vydavatele. Za druhé je nativní aplikace nakonfigurovaná tak, aby označovala oprávnění, která potřebuje k tomu, aby byla funkční. Tento seznam požadovaných oprávnění se zobrazí v dialogovém okně, když uživatel nebo správce v cílovém adresáři udělí souhlas aplikaci a zpřístupní ho jeho organizaci. Některé aplikace vyžadují jenom oprávnění na úrovni uživatele, se kterými může souhlasit každý uživatel v organizaci. Jiné aplikace vyžadují oprávnění na úrovni správce, se kterými uživatel v organizaci nemůže souhlasit. Pouze správce adresáře může udělit souhlas aplikacím, které vyžadují tuto úroveň oprávnění. Když uživatel nebo správce souhlasí, je v jeho adresáři zaregistrované jenom webové rozhraní API.

Vypršení platnosti tokenu

Když nativní aplikace použije svůj autorizační kód k získání přístupového tokenu JWT, obdrží také obnovovací token JWT. Po vypršení platnosti přístupového tokenu lze obnovovací token použít k opětovnému ověření uživatele, aniž by se musel znovu přihlásit. Tento obnovovací token se pak použije k ověření uživatele, což vede k vytvoření nového přístupového tokenu a obnovovacího tokenu.

Další kroky