Sdílet prostřednictvím

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

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ě Azure App Service.

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

Konfigurace webu Azure Portal nenabízí způsob, jak uživatelům prezentovat více poskytovatelů přihlašování. Můžete například chtít jako možnosti nabízet Facebook i X. Přidání několika poskytovatelů přihlašování do aplikace:

  1. Na webu Azure Portal ve webové aplikaci vyberte Ověřování nastavení>.

  2. V části Nastavení ověřování vyberte Upravit.

  3. Pokud chcete omezit přístup, vyberte Povolit neověřený přístup.

  4. Na přihlašovací stránce, navigačním panelu nebo jiném umístění v aplikaci přidejte přihlašovací odkaz na každého z poskytovatelů, 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 vybere některý z odkazů, otevře se příslušná stránka pro přihlášení.

Pokud chcete uživatele po přihlášení přesměrovat na vlastní adresu URL, použijte parametr řetězce dotazu post_login_redirect_uri. Pokud například chcete uživatele po přihlášení přesunout na /Home/Index, použijte následující kód HTML:

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

Poznámka:

Nesplést tuto hodnotu s přesměrovacím identifikátorem URI v konfiguraci zprostředkovatele identity.

#D0 Použít 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ého pro zprostředkovatele. Kód aplikace pak odešle výsledný ověřovací token službě App Service k ověření pomocí požadavku HTTP POST . Samotné ověření neuděluje uživatelům přístup k požadovaným prostředkům aplikace. Úspěšné ověření poskytuje uživatelům relaceový token, který mohou použít pro přístup k prostředkům aplikace. Další informace najdete v tématu Průběh autentizace.

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 poskytovatele, odešlete token k /.auth/login/<provider> pro 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:

Hodnota zprostředkovatele Požadováno v textu požadavku Komentáře
aad {"access_token":"<access_token>"} Vlastnosti id_tokena refresh_token , expires_injsou volitelné.
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ě pro tokeny. Když zadáte authorization_code, můžete jej případně doplnit o vlastnost redirect_uri.
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 vrátí hodnotu authenticationToken v textu odpovědi. Tato hodnota je token relace. Další informace o uživatelských nárocích naleznete v části Práce s uživatelskými identitami v ověřování Azure App 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>

Odhlaste se z relace

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

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

Tady je jednoduchý odkaz pro odhlášení na webové stránce:

<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čujeme, abyste kódovali hodnotu post_logout_redirect_uri.

Pokud používáte plně kvalifikované adresy 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. Následující příklad přesměruje na URL https://myexternalurl.com, která není umístěná ve stejné doméně:

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

Spusťte následující příkaz v Azure Cloud Shell:

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 fragmenty adres URL (například #B2) nejsou nikdy odesílány na server, nejsou zachovány ve výchozím nastavení ještě před dokončením přihlášení OAuth a přesměrováním zpět do vaší aplikace. Uživatelé pak mají suboptimální zážitky, když musí 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í služby App Service můžete zachovat fragmenty adres URL v rámci přihlášení OAuth nastavením WEBSITE_AUTH_PRESERVE_URL_FRAGMENT na true. Toto nastavení aplikace použijete v prostředí Azure portal nebo můžete ve Cloud Shellu spustit následující příkaz:

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ě pro přihlašovací účty

Účty Microsoft i Microsoft Entra umožňují uživatelům přihlásit se z více domén. Například účet Microsoft umožňuje účty #B0, #B1 a #D2. 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 svou 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 Průzkumníku prostředků v horní části stránky vyberte Čtení/Zápis.

  2. V levém podokně přejděte na předplatná>název předplatného>skupiny prostředků>název skupiny prostředků>poskytovatelé>Microsoft.Web>stránky>název aplikace>konfigurace>authsettingsV2.

  3. Vyberte položku Upravit.

  4. Přidejte pole s položkou:

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

  5. Vyberte Vložit.

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

Důležité

Je možné, aby klient po přijetí adresy URL přesměrování odebral parametr domain_hint a pak se přihlásil s jinou doménou. I když je tato funkce pohodlná, není to funkce zabezpečení.

Autorizace nebo zamítnutí uživatelů

App Service se postará o nejjednodušší případ autorizace, například odmítnutí neověřených požadavků. Vaše aplikace může vyžadovat jemněji odstupňované chování autorizace, například omezení přístupu jenom na konkrétní skupinu uživatelů.

Možná budete muset napsat vlastní kód aplikace, který povolí nebo odepře přístup přihlášeného uživatele. V některý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)

Pro jakoukoli aplikaci pro Windows můžete definovat autorizaci webového serveru IIS úpravou souboru web.config. Aplikace pro Linux nepoužívají službu IIS a není možné je nakonfigurovat prostřednictvím web.config.

  1. Pokud chcete přejít do konzoly ladění Kudu pro vaši aplikaci, vyberteRozšířené nástroje>pro vývoja vyberte Přejít. Pak vyberte konzoli ladění.

    Tuto stránku můžete otevřít také s touto adresou URL: https://<app-name>-<random-hash>.scm.<region>.azurewebsites.net/DebugConsole. Pokud chcete získat náhodné hodnoty hash a oblasti, zkopírujte v přehledu aplikace výchozí doménu.

  2. V průzkumníku souborů služby App Service přejděte na site/wwwroot. Pokud #D0 neexistuje, vytvořte ho tak, že vyberete #B1 #A2 #A3 Nový soubor #A4 .

  3. Vyberte tužku pro web.config k úpravě souboru. Přidejte následující konfigurační kód a pak vyberte #B0 Uložit #A1 . Pokud #D0 již existuje, stačí přidat prvek #D1 se vším v něm. Do elementu #D0 přidejte účty, které chcete 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ň poskytovatele identity

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

Úroveň aplikace

Pokud ani jedna z ostatních úrovní neposkytuje autorizaci, kterou potřebujete, nebo pokud vaše platforma nebo zprostředkovatel identity není podporován, musíte napsat vlastní kód pro autorizaci uživatelů na základě uživatelských deklarací.

Související obsah