Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Výstraha
Tento obsah je určený pro starší koncový bod Azure AD verze 1.0. Pro nové projekty použijte platformu Microsoft Identity Platform.
OpenID Connect je jednoduchá vrstva identity založená na protokolu OAuth 2.0. OAuth 2.0 definuje mechanismy pro získání a použití přístupových tokenů pro přístup k chráněným prostředkům, ale nedefinují standardní metody pro poskytování informací o identitě. OpenID Connect implementuje ověřování jako rozšíření procesu autorizace OAuth 2.0. Poskytuje informace o koncovém uživateli ve formě id_token ověření identity uživatele a poskytuje základní profilové informace o uživateli.
OpenID Connect je naše doporučení, pokud vytváříte webovou aplikaci hostovanou na serveru a přistupujete přes prohlížeč.
Registrujte aplikaci u svého tenantu AD
Nejprve zaregistrujte aplikaci v tenantovi Azure Active Directory (Azure AD). Tím získáte ID aplikace pro vaši aplikaci a umožníte mu přijímat tokeny.
Přihlaste se do Azure Portalu.
Vyberte svého tenanta Azure AD tím, že zvolíte svůj účet v pravém horním rohu stránky, poté zvolíte navigaci Přepnout adresář a vyberete příslušného tenanta.
- Tento krok přeskočte, pokud máte ve svém účtu jenom jednoho tenanta Azure AD nebo pokud jste už vybrali příslušného tenanta Azure AD.
Na webu Azure Portal vyhledejte a vyberte Azure Active Directory .
V levém menu Azure Active Directory vyberte možnost Registrace aplikacía poté vyberte Nová registrace.
Postupujte podle pokynů a vytvořte novou aplikaci. Nezáleží na tom, jestli se jedná o webovou aplikaci nebo veřejnou klientskou aplikaci (mobilní & desktopovou) pro účely tohoto kurzu, ale pokud chcete konkrétní příklady webových aplikací nebo veřejných klientských aplikací, podívejte se na naše rychlé starty.
- Název je název aplikace a popisuje aplikaci koncovým uživatelům.
- V části Podporované typy účtů vyberte Účty v libovolném adresáři organizace a osobních účtech Microsoft.
- Zadejte identifikátor URI přesměrování. U webových aplikací je to základní adresa URL vaší aplikace, kde se uživatelé můžou přihlásit. Například
http://localhost:12345. Pro veřejného klienta (mobilní & desktop) ji Azure AD používá k vrácení odpovědí na tokeny. Zadejte hodnotu specifickou pro vaši aplikaci. Napříkladhttp://MyFirstAADApp.
Po dokončení registrace přiřadí Azure AD vaší aplikaci jedinečný identifikátor klienta (ID aplikace ). Tuto hodnotu budete potřebovat v dalších částech, proto ji zkopírujte ze stránky aplikace.
Pokud chcete najít aplikaci na webu Azure Portal, vyberte registrace aplikacía pak vyberte Zobrazit všechny aplikace.
Tok ověřování pomocí OpenID Connect
Nejzásadnější tok přihlašování obsahuje následující kroky – každý z nich je podrobně popsaný níže.
Dokument metadat OpenID Connect
OpenID Connect popisuje dokument metadat, který obsahuje většinu informací potřebných k přihlášení aplikace. To zahrnuje informace, jako jsou adresy URL, které se mají použít, a umístění veřejných podpisových klíčů služby. Dokument metadat OpenID Connect najdete tady:
https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration
Metadata jsou jednoduchý dokument JSON (JavaScript Object Notation). Příklad najdete v následujícím fragmentu kódu. Obsah fragmentu kódu je plně popsaný ve specifikaci OpenID Connect. Všimněte si, že zadání ID tenanta místo common {tenant} výše způsobí vrácené identifikátory URI specifické pro tenanta.
{
"authorization_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/authorize",
"token_endpoint": "https://login.microsoftonline.com/{tenant}/oauth2/token",
"token_endpoint_auth_methods_supported":
[
"client_secret_post",
"private_key_jwt",
"client_secret_basic"
],
"jwks_uri": "https://login.microsoftonline.com/common/discovery/keys"
"userinfo_endpoint":"https://login.microsoftonline.com/{tenant}/openid/userinfo",
...
}
Pokud má vaše aplikace vlastní podpisové klíče v důsledku použití funkce mapování deklarací identity , musíte přidat appid parametr dotazu obsahující ID aplikace, abyste získali jwks_uri odkazující na informace o podpisovém klíči vaší aplikace. Například: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e obsahuje jwks_uri hodnotu https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e.
Odeslání žádosti o přihlášení
Pokud vaše webová aplikace potřebuje ověřit uživatele, musí uživatele směrovat na /authorize koncový bod. Tento požadavek se podobá první části toku autorizačního kódu OAuth 2.0 s několika důležitými rozdíly:
- Požadavek musí obsahovat obor
openidv parametruscope. - Parametr
response_typemusí obsahovatid_token. - Požadavek musí obsahovat
nonceparametr.
Ukázková žádost by tedy vypadala takto:
// Line breaks for legibility only
GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%3a12345
&response_mode=form_post
&scope=openid
&state=12345
&nonce=7362CAEA-9CA5-4B43-9BA3-34D7C303EBA7
| Parametr | Typ | Popis |
|---|---|---|
| nájemník | povinné |
{tenant} Hodnotu v cestě požadavku můžete použít k řízení, kdo se může přihlásit k aplikaci. Povolené hodnoty jsou identifikátory tenantů, například 8eaef023-2b34-4da1-9baa-8bc8c9d6a490 nebo contoso.onmicrosoft.com nebo common pro tokeny nezávislé na tenantovi. |
| identifikátor klienta | povinné | ID aplikace přiřazené vaší aplikaci, když jste ho zaregistrovali ve službě Azure AD. Najdete ho na webu Azure Portal. Klikněte na Azure Active Directory, klikněte na Registrace aplikací, zvolte aplikaci a na stránce aplikace vyhledejte ID aplikace. |
| typ_odezvy | povinné | Musí obsahovat id_token pro přihlášení openID Connect. Může obsahovat také jiné response_types, například code nebo token. |
| rozsah | Doporučené | Specifikace OpenID Connect vyžaduje obor openid, který se v uživatelském rozhraní pro vyjádření souhlasu překládá na oprávnění Přihlásit se. Tento a další obory OIDC se na koncovém bodu verze 1.0 ignorují, ale stále se doporučuje pro klienty vyhovující standardům. |
| nonce | povinné | Hodnota zahrnutá v požadavku, vygenerovaná aplikací, která je součástí výsledného id_token jako nárok. Aplikace pak může tuto hodnotu ověřit, aby se omezily útoky typu přehrání tokenu. Hodnota je obvykle randomizovaný, jedinečný řetězec nebo guid, které lze použít k identifikaci původu požadavku. |
| URI přesměrování (redirect_uri) | Doporučené | Redirect_uri vaší aplikace, kde může vaše aplikace odesílat a přijímat odpovědi na ověřování. Musí přesně odpovídat některému z redirect_uris, který jste zaregistrovali na portálu, s výjimkou toho, že musí být kódován adresou URL. Pokud chybí, bude uživatelský agent náhodně odeslán zpět na jednu z přesměrovacích URI zaregistrovaných pro aplikaci. Maximální délka je 255 bajtů. |
| mód odezvy | volitelný | Určuje metodu, která se má použít k odeslání výsledného authorization_code zpět do vaší aplikace. Podporované hodnoty jsou form_post pro příspěvek formuláře HTTP a fragment pro fragment adresy URL. U webových aplikací doporučujeme použít response_mode=form_post k zajištění nejbezpečnějšího přenosu tokenů do vaší aplikace. Výchozí hodnota pro jakýkoli tok včetně id_token je fragment. |
| stát | Doporučené | Hodnota zahrnutá v požadavku, která je vrácena v odpovědi na token. Může to být řetězec libovolného obsahu. Náhodně vygenerovaná jedinečná hodnota se obvykle používá k zabránění útokům typu CSRF (Cross-Site Request Forgery). Stav se také používá ke kódování informací o stavu uživatele v aplikaci před tím, než došlo k žádosti o ověření, jako je stránka nebo zobrazení, na které byli. |
| výzva | volitelný | Určuje typ interakce uživatele, který je povinný. V současné době jsou jedinými platnými hodnotami 'přihlášení', 'none' a 'consent'.
prompt=login vynutí, aby uživatel zadal své přihlašovací údaje k této žádosti a neguje jednotné přihlašování.
prompt=none je opak - zajišťuje, že uživatel nebude prezentován s žádnou interaktivní výzvou vůbec. Pokud požadavek nelze dokončit bezobslužně prostřednictvím jednotného přihlašování, vrátí koncový bod chybu.
prompt=consent aktivuje dialogové okno souhlasu OAuth po přihlášení uživatele a požádá uživatele o udělení oprávnění aplikaci. |
| nápověda k přihlášení | volitelný | Dá se použít k předběžnému vyplnění pole uživatelské jméno a e-mailová adresa přihlašovací stránky pro uživatele, pokud znáte své uživatelské jméno předem. Aplikace často tento parametr používá při opětovném ověření, přičemž už dříve extrahovala uživatelské jméno z předchozího přihlášení pomocí nároku preferred_username. |
V tomto okamžiku se uživateli zobrazí výzva k zadání přihlašovacích údajů a dokončení ověřování.
Ukázková odpověď
Ukázková odpověď odeslaná na zadanou redirect_uri žádost o přihlášení po ověření uživatele může vypadat takto:
POST / HTTP/1.1
Host: localhost:12345
Content-Type: application/x-www-form-urlencoded
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&state=12345
| Parametr | Popis |
|---|---|
| identifikační token | Aplikace požadovala id_token. Můžete použít id_token k ověření identity uživatele a zahájení relace s uživatelem. |
| stát | Hodnota zahrnutá v požadavku, která se také vrátí v odpovědi tokenu. Náhodně vygenerovaná jedinečná hodnota se obvykle používá k zabránění útokům typu CSRF (Cross-Site Request Forgery). Stav se také používá ke kódování informací o stavu uživatele v aplikaci před tím, než došlo k žádosti o ověření, jako je stránka nebo zobrazení, na které byli. |
Chybová odpověď
Chybové odpovědi se můžou také odeslat do redirect_uri aplikace, aby je mohla správně zpracovat:
POST / HTTP/1.1
Host: localhost:12345
Content-Type: application/x-www-form-urlencoded
error=access_denied&error_description=the+user+canceled+the+authentication
| Parametr | Popis |
|---|---|
| chyba | Řetězec kódu chyby, který lze použít ke klasifikaci typů chyb, ke kterým dochází, a lze jej použít k reakci na chyby. |
| popis chyby | Konkrétní chybová zpráva, která může vývojáři pomoct identifikovat původní příčinu chyby ověřování. |
Kódy chyb pro chyby na koncovém bodu autorizace
Následující tabulka popisuje různé kódy chyb, které lze vrátit v error parametru chybové odpovědi.
| Kód chyby | Popis | Akce klienta |
|---|---|---|
| neplatný_požadavek | Chyba protokolu, například chybějící požadovaný parametr. | Opravte požadavek a odešlete ho znovu. Jedná se o chybu vývoje, která se obvykle chytí během počátečního testování. |
| neautorizovaný_klient | Klientská aplikace nemá oprávnění požadovat autorizační kód. | K tomu obvykle dochází v případě, že klientská aplikace není zaregistrovaná v Azure AD nebo není přidána do tenanta Azure AD uživatele. Aplikace může uživatele vyzvat k instalaci aplikace a jejímu přidání do Azure AD. |
| přístup odepřen | Vlastník prostředku zamítl souhlas | Klientská aplikace může uživatele upozornit, že nemůže pokračovat, pokud uživatel souhlasí. |
| nepodporovaný_typ_odezvy | Autorizační server nepodporuje typ odpovědi v požadavku. | Opravte požadavek a odešlete ho znovu. Jedná se o chybu vývoje, která se obvykle chytí během počátečního testování. |
| chyba serveru | Server zjistil neočekávanou chybu. | Zkuste požadavek zopakovat. Tyto chyby můžou mít za následek dočasné podmínky. Klientská aplikace může uživateli vysvětlit, že jeho odpověď je zpožděná kvůli dočasné chybě. |
| dočasně nedostupné | Server je dočasně příliš zaneprázdněný pro zpracování požadavku. | Zkuste požadavek zopakovat. Klientská aplikace může uživateli vysvětlit, že jeho odpověď je zpožděná kvůli dočasné podmínce. |
| neplatný zdroj | Cílový prostředek je neplatný, protože neexistuje, Azure AD ho nemůže najít nebo není správně nakonfigurovaný. | To značí, že prostředek, pokud existuje, nebyl v tenantovi nakonfigurován. Aplikace může uživatele vyzvat k instalaci aplikace a jejímu přidání do Azure AD. |
Ověřte id_token
Pouhé přijetí id_token nestačí k ověření uživatele; musíte ověřit podpis a ověřit nároky v id_token podle požadavků vaší aplikace. Koncový bod Azure AD používá webové tokeny JSON (JWT) a kryptografii veřejného klíče k podepisování tokenů a ověření jejich platnosti.
Můžete se rozhodnout ověřit id_token kód klienta, ale běžným postupem je odeslání id_token na back-endový server a provedení ověření tam.
Můžete chtít také ověřit další nároky v závislosti na vašem scénáři. Mezi běžná ověření patří:
- Zajištění registrace uživatele nebo organizace k aplikaci
- Zajištění, že má uživatel správnou autorizaci nebo oprávnění pomocí nároků
widsneboroles. - Zajištění toho, že došlo k určité síle autentizace, jako je vícefaktorová autentizace.
Jakmile ověříte id_token, můžete zahájit relaci s uživatelem a použít údaje v id_token k získání informací o uživateli ve vaší aplikaci. Tyto informace lze použít pro zobrazení, záznamy, přizpůsobení atd. Další informace o id_tokens službě AAD a deklarací identity najdete v id_tokens.
Odeslání žádosti o odhlášení
Pokud chcete uživatele odhlásit z aplikace, nestačí vymazat soubory cookie aplikace nebo ukončit relaci s uživatelem. Uživatele musíte také přesměrovat na end_session_endpoint odhlašování. Pokud to neuděláte, uživatel bude moct aplikaci znovu ověřovat bez opětovného zadání přihlašovacích údajů, protože bude mít platnou relaci jednotného přihlašování s koncovým bodem Azure AD.
Uživatele můžete jednoduše přesměrovat na end_session_endpoint uvedený v dokumentu metadat OpenID Connect:
GET https://login.microsoftonline.com/common/oauth2/logout?
post_logout_redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
| Parametr | Typ | Popis |
|---|---|---|
| post_logout_redirect_uri | Doporučené | Adresa URL, na kterou se má uživatel po úspěšném odhlášení přesměrovat. Tato adresa URL musí odpovídat jednomu z identifikátorů URI přesměrování zaregistrovaných pro vaši aplikaci na portálu pro registraci aplikací. Pokud post_logout_redirect_uri není zahrnut, zobrazí se uživateli obecná zpráva. |
Jednotné odhlašování
Když uživatele přesměrujete na end_session_endpoint, Azure AD vymaže relaci uživatele z prohlížeče. Uživatel se ale stále může přihlásit k jiným aplikacím, které k ověřování používají Azure AD. Aby se tyto aplikace odhlásily současně, Azure AD odešle požadavek HTTP GET na zaregistrované LogoutUrl všechny aplikace, ke kterým je uživatel aktuálně přihlášený. Aplikace musí na tento požadavek reagovat tím, že vymaže jakoukoli relaci, která identifikuje uživatele, a vrátí 200 odpověď. Pokud chcete podporovat jednotné odhlášení v aplikaci, musíte takový LogoutUrl kód implementovat v kódu vaší aplikace. Můžete nastavit LogoutUrl na webu Azure Portal:
- Přihlaste se do Azure Portalu.
- Vyberte službu Active Directory kliknutím na svůj účet v pravém horním rohu stránky.
- Na levém navigačním panelu zvolte Azure Active Directory, pak zvolte Registrace aplikací a vyberte svou aplikaci.
- Klikněte na Nastavení, potom na Vlastnosti a vyhledejte textové pole Adresa URL pro odhlášení .
Získání tokenu
Mnoho webových aplikací musí nejen přihlásit uživatele, ale také přistupovat k webové službě jménem tohoto uživatele pomocí OAuth. Tento scénář kombinuje OpenID Connect pro ověřování uživatelů a současně získává authorization_code, který může být použit k získání access_tokens za použití OAuth autorizačního toku kódu.
Získání přístupových tokenů
Pokud chcete získat přístupové tokeny, musíte upravit žádost o přihlášení z výše uvedeného příkladu:
// Line breaks for legibility only
GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e // Your registered Application ID
&response_type=id_token+code
&redirect_uri=http%3A%2F%2Flocalhost%3a12345 // Your registered Redirect Uri, url encoded
&response_mode=form_post // `form_post' or 'fragment'
&scope=openid
&resource=https%3A%2F%2Fservice.contoso.com%2F // The identifier of the protected resource (web API) that your application needs access to
&state=12345 // Any value, provided by your app
&nonce=678910 // Any value, provided by your app
Zahrnutím rozsahů oprávnění do požadavku a použití response_type=code+id_tokenzajišťuje koncový bod, authorize že uživatel souhlasil s oprávněními uvedenými v parametru scope dotazu, a vrátí autorizační kód, který se má vyměnit za přístupový token.
Úspěšná odpověď
Úspěšná odpověď odeslaná do redirect_uri pomocí response_mode=form_post vypadá takto:
POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNB...&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...&state=12345
| Parametr | Popis |
|---|---|
| identifikační token | Aplikace požadovala id_token. Můžete použít id_token k ověření identity uživatele a zahájení relace s uživatelem. |
| kód | Autorizační kód, který aplikace požadovala. Aplikace může použít autorizační kód k vyžádání přístupového tokenu pro cílový prostředek. Authorization_codes jsou krátkodobé a obvykle vyprší po přibližně 10 minutách. |
| stát | Pokud je v požadavku zahrnutý parametr stavu, měla by se v odpovědi zobrazit stejná hodnota. Aplikace by měla ověřit, že hodnoty stavu v požadavku a odpovědi jsou identické. |
Chybová odpověď
Chybové odpovědi se můžou také odeslat do redirect_uri aplikace, aby je mohla správně zpracovat:
POST /myapp/ HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
error=access_denied&error_description=the+user+canceled+the+authentication
| Parametr | Popis |
|---|---|
| chyba | Řetězec kódu chyby, který lze použít ke klasifikaci typů chyb, ke kterým dochází, a lze jej použít k reakci na chyby. |
| popis chyby | Konkrétní chybová zpráva, která může vývojáři pomoct identifikovat původní příčinu chyby ověřování. |
Popis možných kódů chyb a jejich doporučené akce klienta najdete v tématu Kódy chyb pro chyby koncového bodu autorizace.
Jakmile získáte autorizaci code a id_token, můžete přihlásit uživatele a získat přístupové tokeny jako uživatele. Pokud chcete uživatele přihlásit, musíte ověřit id_token přesně tak, jak je popsáno výše. Pokud chcete získat přístupové tokeny, můžete postupovat podle kroků popsaných v části Použití autorizačního kódu k vyžádání přístupového tokenu v dokumentaci k toku kódu OAuth.
Další kroky
- Přečtěte si další informace o přístupových tokenech.
- Přečtěte si další informace o deklaracích
id_tokena nárocích.