在 Azure App Service 驗證中自訂登入和登出
本文說明在使用內建的 App Service 中的驗證和授權時,如何自訂使用者登入和登出。
使用多個登入提供者
入口網站設定不提供轉折方式,將多個登入提供者呈現給使用者(例如 Facebook 和 X)。 不過,要將功能新增至您的應用程式並不困難。 步驟概述如下:
首先,在 Azure 入口網站的 [驗證/授權] 頁面中,設定您需要啟用的每一個識別提供者。
在 [當要求未經驗證時所要採取的動作] 中,選取 [允許匿名要求 (無動作)]。
在登入頁面或導覽列、或是您應用程式的任何其他位置中,將登入連結新增至您啟用的每個提供者 (/.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
查詢字串參數 (請勿與您身分識別提供者組態中的重新導向 URI 混淆)。 例如,若要在使用者登入之後,將他們導向 /Home/Index
,請使用下列 HTML 程式碼:
<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>
用戶端導向的登入
在用戶端導向的登入中,應用程式使用提供者專用 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_token 、refresh_token 和 expires_in 是選用屬性。 |
microsoftaccount |
{"access_token":"<access_token>"} 或 {"authentication_token": "<token>" |
authentication_token 優先於 access_token 。 expires_in 是選用屬性。 從即時服務要求權杖時,請一律要求 wl.basic 範圍。 |
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 服務 驗證中使用使用者身分識別。
{
"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
:
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 驗證中,您可以在 OAuth 登入保留 URL 片段。 若要這麼做,將稱為 WEBSITE_AUTH_PRESERVE_URL_FRAGMENT
的應用程式設定設為 true
。 您可以在 Azure 入口網站中這麼做,也可以直接在 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.com、live.com 和 hotmail.com 帳戶。 Microsoft Entra 不限制登入帳戶的自訂網域數目。 不過,最好儘快讓使用者直接連到您自有品牌的 Microsoft Entra 登入頁面 (例如 contoso.com
)。 若要建議登入帳戶的網域名稱,請遵循下列步驟。
在 https://resources.azure.com 中,在頁面頂端選取 [讀取/寫入]。
在左側瀏覽器中,巡覽至 subscriptions><subscription-name>resourceGroups><resource-group-name>>providers>Microsoft.Web>sites><app-name>>config>authsettingsV2。
按一下 [編輯] 。
新增
loginParameters
陣列和domain_hint
項目。"identityProviders": { "azureActiveDirectory": { "login": { "loginParameters": ["domain_hint=<domain-name>"], } } }
按一下 [放置]。
此設定將 domain_hint
查詢字串參數附加至登入重新導向 URL。
重要
用戶端在收到重新導向 URL 之後可能移除 domain_hint
參數,然後以不同的網域登入。 雖然此功能很方便,但不安全。
授權或拒絕使用者
App Service 只處理最簡單的授權情況 (亦即拒絕未經驗證的要求),但您的應用程式可能需要更精細的授權行為,例如僅限一群特定的使用者才能存取。 在某些情況下,您必須撰寫自訂應用程式程式碼,以允許或拒絕登入的使用者存取。 在其他情況下,App Service 或識別提供者或許可以協助您,而不需要變更程式碼。
伺服器層級 (僅限 Windows 應用程式)
對於任何 Windows 應用程式,您可以編輯 Web.config 檔案來定義 IIS 網頁伺服器的授權行為。 Linux 應用程式不使用 IIS,無法透過 Web.config 來設定。
導覽到
https://<app-name>.scm.azurewebsites.net/DebugConsole
在 App Service 檔案的瀏覽器總管中,巡覽至 site/wwwroot。 如果 Web.config 不存在,請選取 [+]>[新增檔案] 來建立此檔案。
選取 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>
識別提供者層級
識別提供者可能提供某種現成的授權。 例如:
- 您可以直接在 Microsoft Entra 中管理企業層級存取。 如需相關指示,請參閱如何移除使用者對應用程式的存取權。
- 針對 Google,屬於組織的 Google API 專案可以設定為只允許組織中的使用者才能存取 (請參閱 Google 的設定 OAuth 2.0 支援頁面)。
應用程式層級
如果其他層級都未提供您需要的授權,或不支援您的平台或識別提供者,您必須撰寫自訂程式碼,以根據使用者宣告來授權使用者。