Sdílet prostřednictvím

Přizpůsobení přihlášení a odhlášení v ověřování služby Aplikace Azure

  • Článek

V tomto článku se dozvíte, jak přizpůsobit přihlášení a odhlášení uživatelů při používání integrovaného ověřování a autorizace ve službě App Service.

Použití více poskytovatelů přihlašování

Konfigurace portálu nenabízí způsob, jak uživatelům prezentovat více poskytovatelů přihlašování (například Facebook i X). Není ale obtížné do aplikace přidat funkce. Postup je uveden níže:

Nejprve na stránce Ověřování nebo autorizace na webu Azure Portal nakonfigurujte každého zprostředkovatele identity, kterého chcete povolit.

V akci, která se má provést, když požadavek není ověřený, vyberte Povolit anonymní žádosti (bez akce).

Na přihlašovací stránce nebo na navigačním panelu nebo v jiném umístění vaší aplikace přidejte odkaz pro přihlášení ke každému poskytovateli, který jste povolili (/.auth/login/<provider>). Příklad:

<a href="/.auth/login/aad">Log in with Microsoft Entra</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>
<a href="/.auth/login/apple">Log in with Apple</a>

Když uživatel klikne na některý z odkazů, otevře se příslušná přihlašovací stránka pro přihlášení uživatele.

Pokud chcete uživatele po přihlášení přesměrovat na vlastní adresu URL, použijte post_login_redirect_uri parametr řetězce dotazu (nezaměňte s identifikátorem URI přesměrování v konfiguraci zprostředkovatele identity). Pokud chcete například přejít uživatele po /Home/Index přihlášení, použijte následující kód HTML:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Přihlášení řízené klientem

V přihlášení řízeném klientem se aplikace přihlásí uživatele k zprostředkovateli identity pomocí sady SDK specifické pro zprostředkovatele. Kód aplikace pak odešle výsledný ověřovací token do služby App Service k ověření (viz tok ověřování) pomocí požadavku HTTP POST. Samotné ověření vám ve skutečnosti neuděluje přístup k požadovaným prostředkům aplikace, ale úspěšné ověření vám poskytne token relace, který můžete použít pro přístup k prostředkům aplikace.

Pokud chcete ověřit token zprostředkovatele, musí být aplikace služby App Service nejprve nakonfigurovaná s požadovaným poskytovatelem. Za běhu po načtení ověřovacího tokenu od zprostředkovatele zastavte token k /.auth/login/<provider> ověření. Příklad:

POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Formát tokenu se mírně liší podle poskytovatele. Podrobnosti najdete v následující tabulce:

Hodnota zprostředkovatele Požadováno v textu požadavku Komentáře
aad {"access_token":"<access_token>"} Vlastnosti id_tokena expires_in , refresh_tokenjsou volitelné.
microsoftaccount {"access_token":"<access_token>"} nebo {"authentication_token": "<token>" authentication_token je upřednostňovaná před access_token. Vlastnost expires_in je nepovinná.
Při vyžádání tokenu ze služeb Live vždy požádejte o wl.basic obor.
google {"id_token":"<id_token>"} Vlastnost authorization_code je nepovinná. Poskytnutí hodnoty authorization_code přidá přístupový token a obnovovací token do úložiště tokenů. Při zadání authorization_code lze také volitelně připojit redirect_uri k vlastnosti.
facebook {"access_token":"<user_access_token>"} Použijte platný přístupový token uživatele z Facebooku.
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

Poznámka:

Poskytovatel GitHubu pro ověřování pomocí služby App Service nepodporuje přizpůsobené přihlašování a odhlášení.

Pokud se token zprostředkovatele úspěšně ověří, rozhraní API se vrátí s textem authenticationToken odpovědi, což je váš token relace. Další informace o deklarací identity uživatelů najdete v tématu Práce s identitami uživatelů v ověřování služby Aplikace Azure Service.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Jakmile budete mít tento token relace, budete mít přístup k chráněným prostředkům aplikace tak, že do požadavků HTTP přidáte hlavičku X-ZUMO-AUTH . Příklad:

GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Odhlášení z relace

Uživatelé můžou zahájit odhlášení odesláním GET žádosti do koncového /.auth/logout bodu aplikace. Požadavek GET provede následující:

  • Vymaže ověřovací soubory cookie z aktuální relace.
  • Odstraní tokeny aktuálního uživatele z úložiště tokenů.
  • Pro Microsoft Entra a Google provede odhlášení na straně serveru u zprostředkovatele identity.

Tady je jednoduchý odkaz na odhlášení z webové stránky:

<a href="/.auth/logout">Sign out</a>

Ve výchozím nastavení úspěšné odhlášení přesměruje klienta na adresu URL /.auth/logout/complete. Stránku přesměrování po odhlášení můžete změnit přidáním parametru post_logout_redirect_uri dotazu. Příklad:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Doporučuje se zakódovat hodnotu post_logout_redirect_uri.

Při použití plně kvalifikovaných adres URL musí být adresa URL hostovaná ve stejné doméně nebo nakonfigurovaná jako povolená adresa URL pro externí přesměrování vaší aplikace. V následujícím příkladu můžete přesměrovat na https://myexternalurl.com to, které není hostované ve stejné doméně:

GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com

V Azure Cloud Shellu spusťte následující příkaz:

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"

Zachování fragmentů adres URL

Když se uživatelé přihlásí k aplikaci, obvykle chtějí být přesměrováni do stejného oddílu stejné stránky, například /wiki/Main_Page#SectionZ. Protože se ale fragmenty adres URL (například #SectionZ) nikdy neodesílají na server, po dokončení přihlášení OAuth a přesměrování zpět do vaší aplikace se ve výchozím nastavení nezachovají. Uživatelé pak získají neoptimální prostředí, když potřebují znovu přejít na požadované ukotvení. Toto omezení platí pro všechna řešení ověřování na straně serveru.

V ověřování ve službě App Service můžete zachovat fragmenty adres URL napříč přihlášením OAuth. Chcete-li to provést, nastavte nastavení aplikace volané WEBSITE_AUTH_PRESERVE_URL_FRAGMENT na true. Můžete to udělat na webu Azure Portal nebo jednoduše spustit následující příkaz v Azure Cloud Shellu:

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

Nastavení nápovědy k doméně účtů přihlašování

Účet Microsoft i Microsoft Entra vám umožní přihlásit se z více domén. Účet Microsoft například umožňuje účty outlook.com, live.com a hotmail.com . Microsoft Entra umožňuje pro přihlašovací účty libovolný počet vlastních domén. Můžete ale chtít urychlit uživatele přímo na vlastní přihlašovací stránku Microsoft Entra (například contoso.com). Pokud chcete navrhnout název domény přihlašovacích účtů, postupujte takto.

  1. V https://resources.azure.comhorní části stránky vyberte Čtení a zápis.

  2. V levém prohlížeči přejděte do předplatných<>název_předplatného>resourceGroups<>resource-group-name>>providers>Microsoft.Web>sites<>app-name>>config>authsettingsV2.

  3. Klikněte na možnost Upravit.

  4. loginParameters Přidejte pole s položkoudomain_hint.

    "identityProviders": {
    "azureActiveDirectory": {
        "login": {
            "loginParameters": ["domain_hint=<domain-name>"],
        }
    }
}

  5. Klikněte na Vložit.

Toto nastavení připojí domain_hint parametr řetězce dotazu k adrese URL pro přesměrování přihlášení.

Důležité

Klient může parametr po přijetí adresy URL přesměrování odebrat domain_hint a pak se přihlásit s jinou doménou. I když je tato funkce pohodlná, není to funkce zabezpečení.

Autorizace nebo zamítnutí uživatelů

I když se služba App Service postará o nejjednodušší případ autorizace (tj. odmítnutí neověřených požadavků), může vaše aplikace vyžadovat jemněji odstupňované chování autorizace, například omezení přístupu jenom na konkrétní skupinu uživatelů. V některých případech musíte napsat vlastní kód aplikace, který povolí nebo odepře přístup přihlášeného uživatele. V jiných případech může služba App Service nebo váš zprostředkovatel identity pomoct bez nutnosti změn kódu.

Úroveň serveru (jenom aplikace pro Windows)

U jakékoli aplikace pro Windows můžete definovat chování autorizace webového serveru IIS úpravou souboru Web.config . Linuxové aplikace nepoužívají službu IIS a není možné je nakonfigurovat prostřednictvím web.config.

  1. Přejděte na adresu https://<app-name>.scm.azurewebsites.net/DebugConsole

  2. V průzkumníku prohlížeče souborů služby App Service přejděte na web/wwwroot. Pokud web.config neexistuje, vytvořte ho výběrem možnosti +>Nový soubor.

  3. Vyberte tužku pro Web.config a upravte ji. Přidejte následující konfigurační kód a klikněte na Uložit. Pokud web.config již existuje, stačí přidat <authorization> prvek se vším v něm. Přidejte účty, které chcete v elementu <allow> povolit.

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
   <system.web>
      <authorization>
        <allow users="user1@contoso.com,user2@contoso.com"/>
        <deny users="*"/>
      </authorization>
   </system.web>
</configuration>

Úroveň zprostředkovatele identity

Zprostředkovatel identity může poskytnout určitou autorizaci na klíč. Příklad:

Úroveň aplikace

Pokud některé z dalších úrovní neposkytuje potřebnou autorizaci nebo pokud vaše platforma nebo zprostředkovatel identity není podporovaný, musíte napsat vlastní kód, který autorizuje uživatele na základě deklarací identity uživatele.

Další materiály