共用方式為


在 Azure App Service 驗證中自定義登入和登出

本文說明如何在 Azure App Service 中使用內建的驗證和授權,自定義使用者登入和註銷。

使用多個登入提供者

Azure 入口網站設定不會提供周全的方式,向您的使用者顯示多個登入提供者。 例如,您可能想要同時提供 Facebook 和 X 作為選項。 若要將多個登入提供者新增至您的應用程式:

  1. 在 Azure 入口網站的 Web 應用程式中,選取 [ 設定>驗證]。

  2. 針對 [驗證設定],選取 [ 編輯]。

  3. 針對 [限制存取],選取 [允許未經驗證的存取]。

  4. 在登入頁面上,導覽列或您應用程式中的任何其他位置,將登入連結新增至您啟用的每個提供者(/.auth/login/<provider>)。 例如:

    <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>
    

當用戶選取其中一個連結時,會開啟個別頁面以進行登入。

若要在登入之後將使用者重新導向至自定義 URL,請使用 post_login_redirect_uri 查詢字串參數。 例如,若要在登入之後將使用者移至 /Home/Index,請使用下列 HTML 程式代碼:

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

附註

請勿將此值與身分識別提供者設定中的重新導向 URI 混淆。

使用客戶端導向的登入

在客戶端導向的登入中,應用程式會使用提供者特定的 SDK 將使用者登入識別提供者。 應用程式程式代碼接著會使用 HTTP POST 要求,將產生的驗證令牌提交至 App Service 以進行驗證。 此驗證本身不會將所需應用程式資源的存取權授與使用者。 成功的驗證可讓使用者使用會話令牌來存取應用程式資源。 如需詳細資訊,請參閱驗證流程

若要驗證提供者令牌,必須先使用所需的提供者來設定App Service 應用程式。 在執行階段,當您從提供者擷取驗證令牌後,請將令牌發送至 /.auth/login/<provider> 進行驗證。 例如:

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

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

權杖的格式會隨著提供者而稍有不同:

提供者值 要求本文中需要 註解
aad {"access_token":"<access_token>"} id_tokenrefresh_tokenexpires_in 是選用屬性。
google {"id_token":"<id_token>"} authorization_code 是選用屬性。 提供authorization_code值會將存取令牌和更新令牌新增至令牌存放區。 當您指定 authorization_code時,可以選擇性地隨附 redirect_uri 屬性。
facebook {"access_token":"<user_access_token>"} 使用來自 Facebook 的有效使用者存取權杖
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

附註

App Service 驗證的 GitHub 提供者不支援自訂的登入和登出。

如果提供者權杖驗證成功,API 會連同 authenticationToken 值在回應本文中一起傳回。 此值是您的工作階段權杖。 如需使用者宣告的詳細資訊,請參閱 在 Azure App Service 驗證中使用使用者身分識別

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

擁有此工作階段令牌之後,您可以將 X-ZUMO-AUTH 標頭新增至 HTTP 要求,以存取受保護的應用程式資源。 例如:

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

登出工作階段

使用者可以將GET要求傳送到應用程式的/.auth/logout端點以起始登出。 GET 要求:

  • 清除當前會話中的驗證 Cookie。
  • 從權杖存放區中刪除目前使用者的權杖。
  • 在 Microsoft Entra 和 Google 的身分識別提供者上執行伺服器端登出。

以下是網頁上的簡單登出連結:

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

成功登出預設會將用戶端重新導向到 URL /.auth/logout/complete。 您可以新增 post_logout_redirect_uri 查詢參數來變更登出後重新導向頁面。 例如:

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

我們建議您對 post_logout_redirect_uri 的值進行 編碼

當您使用完整的 URL 時,URL 必須裝載於相同的網域,或設定為應用程式允許的外部重新導向 URL。 下列範例會重新導向至未託管於相同網域中的 https://myexternalurl.com URL:

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

Azure Cloud Shell 中執行下列命令:

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

保留 URL 片段

使用者登入您的應用程式之後,通常想要重新導向至相同頁面的相同區段,例如 /wiki/Main_Page#SectionZ。 不過,由於 URL 片段 (例如, #SectionZ)永遠不會傳送至伺服器,因此在 OAuth 登入完成並重新導向回到您的應用程式之後,預設不會保留這些片段。 用戶接著會在需要再次前往所需錨點時獲得次佳體驗。 這項限制適用於所有的伺服器端驗證解決方案。

在 App Service 驗證中,您可以將 設定 WEBSITE_AUTH_PRESERVE_URL_FRAGMENTtrue,在 OAuth 登入中保留 URL 片段。 您可以在 Azure 入口網站中使用此應用程式設定,或在 Cloud Shell 中執行下列命令:

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

設定登入帳戶的網域提示

Microsoft帳戶和Microsoft Entra 讓使用者從多個網域登入。 例如,Microsoft帳戶允許 outlook.comlive.comhotmail.com 帳戶。 Microsoft Entra 不限制登入帳戶的自訂網域數目。 不過,最好儘快讓使用者直接連到您自有品牌的 Microsoft Entra 登入頁面 (例如 contoso.com)。

若要建議登入帳戶的網域名稱,請遵循下列步驟:

  1. [資源總管] 的頁面頂端,選取 [ 讀取/寫入]。

  2. 在左窗格中,移至 subscriptions>subscription-name>resourceGroups>resource-group-name>providers>Microsoft.Web>sites>app-name>config>authsettingsV2

  3. 請選取 ,再編輯

  4. 新增一個包含domain_hint項目的loginParameters陣列:

    "identityProviders": {
        "azureActiveDirectory": {
            "login": {
                "loginParameters": ["domain_hint=<domain-name>"],
            }
        }
    }
    
  5. 選取 [PUT]

此設定會將 domain_hint 查詢字串參數附加至登入重新導向 URL。

重要

用戶端可以在收到重新導向 URL 之後移除 domain_hint 參數,然後使用不同的網域登入。 因此,雖然此函式很方便,但不是安全性功能。

授權或拒絕使用者

App Service 會處理最簡單的授權案例,例如,拒絕未經驗證的要求。 您的應用程式可能需要更精細的授權行為,例如只限制特定使用者群組的存取權。

您可能需要撰寫自定義應用程式程式代碼,以允許或拒絕登入使用者的存取權。 在某些情況下,App Service 或識別提供者或許可以協助您,而不需要變更程式碼。

伺服器層級 (僅限 Windows 應用程式)

針對任何 Windows 應用程式,您可以編輯 web.config 檔案來定義 IIS 網頁伺服器的授權行為。 Linux 應用程式不使用 IIS,且無法透過 web.config進行設定。

  1. 若要移至應用程式的 Kudu 偵錯控制台,請選取 [開發工具進階工具>],然後選取 [移至]。 然後選取 [ 偵錯控制台]。

    您也可以使用此 URL 開啟此頁面: https://<app-name>-<random-hash>.scm.<region>.azurewebsites.net/DebugConsole。 若要取得隨機哈希和區域值,請在您的應用程式 [概 ] 中複製 [預設網域]。

  2. 在 App Service 檔案的瀏覽器總管中,移至 site/wwwroot。 如果 web.config 不存在,請選取 +>[新增檔案] 來建立它。

  3. 選取 web.config 的鉛筆以編輯檔案。 新增下列組態程式代碼,然後選取 [ 儲存]。 如果 web.config 已經存在,只要將連同所有內容的 <authorization> 元素加入即可。 在 元素中 <allow> ,新增您想要允許的帳戶。

    <?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>
    

身分識別提供者層級

識別提供者可能會提供特定的一站式授權。 例如:

應用程式層級

如果其他層級中的任何一個未提供您所需的授權,或者您的平臺或身份提供者不受支援,您必須撰寫自定義程式碼,以便根據使用者宣告來授權使用者。