Co je ověřování?
Upozornění
Tento obsah je určený pro starší koncový bod Azure AD verze 1.0. Pro nové projekty použijte Microsoft identity platform.
Ověřování je vyzvání jedné strany k dodání legitimních přihlašovacích údajů, čímž vzniká základ pro vytvoření objektu zabezpečení sloužícího k řízení identity a přístupu. Jednodušeji řečeno jde o proces prokázání, že jste skutečně tím, kým tvrdíte, že jste. V angličtině se pro ověřování někdy používá zkrácené slovo AuthN.
Autorizace je udělení oprávnění ověřenému objektu zabezpečení, aby mohl něco provést. Určuje, ke kterým datům máte povolený přístup a co s nimi můžete dělat. V angličtině se pro autorizaci někdy používá zkrácené slovo AuthZ.
Azure Active Directory pro vývojáře (v1.0) (Azure AD) zjednodušuje ověřování pro vývojáře tím, že poskytuje identitu jako službu s podporou standardních protokolů, jako jsou OAuth 2.0 a OpenID Connect, a také opensourcových knihoven pro různé platformy, které vám pomůžou rychle začít kódovat.
V modelu programování Azure AD existují dva hlavní případy použití:
- Během toku udělení autorizace OAuth 2.0 – když vlastník prostředku udělí autorizaci klientské aplikaci, čímž klientovi umožní přístup k prostředkům vlastníka prostředku.
- Během přístupu k prostředkům ze strany klienta – podle implementace serverem prostředků, využívání hodnot deklarace identity přítomných v přístupovém tokenu k rozhodování o řízení přístupu na jejich základě.
Základy ověřování v Azure AD
Představme si nejzákladnější scénář, ve kterém se vyžaduje identita: uživatel ve webovém prohlížeči se musí ověřit pro webovou aplikaci. Tento scénář je znázorněný na následujícím diagramu:
Tady je, co potřebujete vědět o různých komponentách zobrazených v diagramu:
- Azure AD je zprostředkovatelem identity. Zprostředkovatel identity zodpovídá za ověření identity uživatelů a aplikací, které existují v adresáři organizace, a po úspěšném ověření těchto uživatelů a aplikací vydává tokeny zabezpečení.
- Aplikace, která chce ověřování outsourcovat na Azure AD, musí být zaregistrovaná v Azure Active Directory (Azure AD). Azure AD aplikaci zaregistruje a jednoznačně identifikuje v adresáři.
- Vývojáři můžou využívat opensourcové knihovny ověřování Azure AD, které ověřování usnadňují tím, že podrobnosti protokolu zpracují za vás. Další informace najdete v tématu knihovny ověřování Microsoft identity platform verze 2.0 a knihovny ověřování verze 1.0.
- Po ověření uživatele musí aplikace ověřit token zabezpečení uživatele, aby se zajistilo úspěšné ověření. K dispozici jsou rychlé starty, kurzy a ukázky kódu v různých jazycích a architekturách, které ukazují, co musí aplikace dělat.
- Pokud chcete rychle vytvořit aplikaci a přidat funkce, jako jsou získání tokenů, aktualizace tokenů, přihlášení uživatele, zobrazení některých informací o uživateli a další, projděte si v dokumentaci sekci Rychlé starty.
- Pokud chcete získat podrobné postupy založené na scénářích pro hlavní ověřovací úkoly pro vývojáře, jako jsou získání přístupových tokenů a jejich používání ve volání rozhraní API Microsoft Graph a dalších rozhraní API, implementace přihlášení s Microsoftem v tradiční aplikaci založené na webovém prohlížeči pomocí OpenID Connect a další úkoly, projděte si v dokumentaci sekci Kurzy.
- Pokud si chcete stáhnout ukázky kódu, přejděte na GitHub.
- Tok požadavků a odpovědí pro proces ověřování závisí na použitém ověřovacím protokolu, jako je OAuth 2.0, OpenID Connect, WS-Federation nebo SAML 2.0. Další informace o protokolech najdete v dokumentaci v části Koncepty > protokolu ověřování .
Ve výše popsaném příkladu scénáře můžete aplikace klasifikovat podle těchto dvou rolí:
- Aplikace, které potřebují zabezpečený přístup k prostředkům
- Aplikace, které hrají roli samotného prostředku
Jak každý tok generuje tokeny a kódy
V závislosti na tom, jak je váš klient sestavený, může používat jeden (nebo několik) toků ověřování podporovaných Azure AD. Tyto toky můžou vytvářet různé tokeny (id_tokens, obnovovací tokeny, přístupové tokeny) i autorizační kódy a k jejich fungování vyžadují různé tokeny. Tento graf poskytuje přehled:
Tok | Vyžaduje | id_token | přístupový token | Obnovovací token | autorizační kód |
---|---|---|---|---|---|
Tok autorizačního kódu | x | x | x | x | |
Implicitní tok | x | x | |||
Hybridní tok OIDC | x | x | |||
Obnovení uplatnění tokenu | Obnovovací token | x | x | x | |
Tok On-Behalf-Of | přístupový token | x | x | x | |
Přihlašovací údaje klienta | x (jenom aplikace) |
Tokeny vydané prostřednictvím implicitního režimu mají omezení délky, protože se předávají zpět do prohlížeče prostřednictvím adresy URL (kde response_mode
je query
nebo fragment
). Některé prohlížeče mají limit velikosti adresy URL, která se dá vložit do panelu prohlížeče, a pokud je příliš dlouhá, selžou. Tyto tokeny tedy nemají ani wids
deklarace groups
identity.
Když teď máte přehled o základech, pokračujte ve čtení, abyste se seznámili s aplikačním modelem identity a rozhraním API, fungováním zřizování v Azure AD a odkazy na podrobné informace o běžných scénářích, které Azure AD podporuje.
Aplikační model
Azure AD zastupuje aplikace podle konkrétního modelu, který je navržený k plnění dvou hlavních funkcí:
Identifikovat aplikaci podle ověřovacího protokolu, který podporuje – to zahrnuje vytvoření výčtu všech identifikátorů, adres URL, tajných kódů a souvisejících informací, které jsou potřeba během ověřování. Azure AD tady:
- Obsahuje všechna data potřebná pro podporu ověřování v době běhu.
- Obsahuje všechna data pro rozhodování o tom, k jakým prostředkům může aplikace potřebovat přístup a jestli by se měl daný požadavek splnit a za jakých okolností.
- Poskytuje infrastrukturu pro implementaci zřizování aplikace v rámci tenanta vývojáře aplikace a do jakéhokoli jiného tenanta Azure AD.
Zpracovat souhlas uživatele během žádosti o token a usnadnit dynamické zřizování aplikací mezi tenanty – tady Azure AD:
- Umožňuje uživatelům a správcům dynamicky udělovat nebo odepírat souhlas s tím, aby aplikace jejich jménem měla přístup k prostředkům.
- Umožňuje správcům nakonec rozhodnout, co můžou aplikace provádět a kteří uživatelé můžou konkrétní aplikace používat a jak se přistupuje k prostředkům adresáře.
Objekt aplikace v Azure AD popisuje aplikaci jako abstraktní entitu. Vývojáři pracují s aplikacemi. Azure AD v době nasazení používá daný objekt aplikace jako podrobný plán k vytvoření instančního objektu, který představuje konkrétní instanci aplikace v rámci adresáře a tenanta. Právě instanční objekt definuje, co aplikace v konkrétním cílovém adresáři ve skutečnosti může dělat, kdo ji může používat, k jakým prostředkům má přístup a tak dále. Azure AD vytváří instanční objekt z objektu aplikace prostřednictvím souhlasu.
Následující diagram znázorňuje zjednodušený tok zřizování v Azure AD s využitím souhlasu. V něm existují dva tenanti (A a B), kde tenant A vlastní aplikaci, a tenant B vytváří instanci aplikace prostřednictvím instančního objektu.
V tomto toku zřizování:
- Uživatel z tenanta B se pokusí přihlásit pomocí aplikace. Autorizační koncový bod požádá o token pro aplikaci.
- Přihlašovací údaje uživatele jsou získány a ověřeny pro ověřování.
- Uživateli se zobrazí výzva k poskytnutí souhlasu, aby aplikace získala přístup k tenantovi B.
- Azure AD používá objekt aplikace v tenantovi A jako podrobný plán pro vytvoření instančního objektu v tenantovi B.
- Uživatel obdrží požadovaný token.
Tento proces můžete libovolně opakovat pro další klienty (C, D a tak dále). Tenant A zachová podrobný plán pro aplikaci (objekt aplikace). Uživatelé a správci všech ostatních tenantů, kde aplikace obdrží souhlas, si zachovají kontrolu nad tím, co aplikace může dělat, prostřednictvím odpovídajícího instančního objektu v každém tenantovi. Další informace najdete v tématu Objekty aplikací a instančních objektů v Microsoft identity platform.
Deklarace identity v tokenech zabezpečení Azure AD
Tokeny zabezpečení (přístupové a ID tokeny) vydané službou Azure AD obsahují deklarace identity neboli tvrzení informací o subjektu, který byl ověřen. Aplikace můžou deklarace identity používat pro různé úkoly, včetně:
- Ověření tokenu
- Identifikace tenanta adresáře subjektu
- Zobrazení informací o uživateli
- Určení autorizace subjektu
Deklarace identity přítomné v jakémkoli tokenu zabezpečení jsou závislé na typu tokenu, typu přihlašovacích údajů pro ověření uživatele a konfiguraci aplikace.
Stručný popis každého typu deklarace identity vygenerovaného službou Azure AD najdete v následující tabulce. Podrobnější informace najdete v přístupových tokenech a tokenech ID vydaných Azure AD.
Deklarovat | Description |
---|---|
ID aplikace | Identifikuje aplikaci, která token používá. |
Cílová skupina | Identifikuje přijímající prostředek, pro který je token určený. |
Reference třídy kontextu ověřování aplikace | Určuje, jak byl klient ověřen (veřejný klient nebo důvěrný klient). |
Okamžik ověření | Zaznamenává datum a čas, kdy k ověření došlo. |
Metoda ověřování | Určuje, jak byl subjekt tokenu ověřen (heslo, certifikát atd.). |
Jméno | Poskytuje křestní jméno uživatele, jak je nastavené v Azure AD. |
Skupiny | Obsahuje ID objektů skupin Azure AD, kterých je uživatel členem. |
Zprostředkovatel identity | Zaznamenává zprostředkovatele identity, který ověřil subjekt tokenu. |
Vystaveno | Zaznamená čas, kdy byl token vystaven, což se často používá pro aktuálnost tokenu. |
Vystavitel | Identifikuje službu tokenů zabezpečení, která token vygenerovala, a také tenanta Azure AD. |
Příjmení | Poskytuje příjmení uživatele, jak je nastavené v Azure AD. |
Name | Poskytuje lidsky čitelnou hodnotu, která identifikuje subjekt tokenu. |
ID objektu | Obsahuje neměnný a jedinečný identifikátor subjektu v Azure AD. |
Role | Obsahuje popisné názvy aplikačních rolí Azure AD, které byly uživateli uděleny. |
Obor | Určuje oprávnění udělená klientské aplikaci. |
Předmět | Určuje objekt zabezpečení, o kterém token prosazuje informace. |
ID tenanta | Obsahuje neměnný a jedinečný identifikátor tenanta adresáře, který token vydal. |
Živostnost tokenu | Definuje časový interval, ve kterém je token platný. |
Hlavní název uživatele | Obsahuje hlavní název uživatele subjektu. |
Verze | Obsahuje číslo verze tokenu. |