本文說明如何在 Azure App Service 中使用內建的驗證和授權,自定義使用者登入和註銷。
使用多個登入提供者
Azure 入口網站設定不會提供周全的方式,向您的使用者顯示多個登入提供者。 例如,您可能想要同時提供 Facebook 和 X 作為選項。 若要將多個登入提供者新增至您的應用程式:
在 Azure 入口網站的 Web 應用程式中,選取 [ 設定>驗證]。
針對 [驗證設定],選取 [ 編輯]。
針對 [限制存取],選取 [允許未經驗證的存取]。
在登入頁面上,導覽列或您應用程式中的任何其他位置,將登入連結新增至您啟用的每個提供者(
/.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_token、refresh_token 和 expires_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_FRAGMENT 為 true,在 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.com、 live.com和 hotmail.com 帳戶。 Microsoft Entra 不限制登入帳戶的自訂網域數目。 不過,最好儘快讓使用者直接連到您自有品牌的 Microsoft Entra 登入頁面 (例如 contoso.com)。
若要建議登入帳戶的網域名稱,請遵循下列步驟:
在 [資源總管] 的頁面頂端,選取 [ 讀取/寫入]。
在左窗格中,移至 subscriptions>subscription-name>resourceGroups>resource-group-name>providers>Microsoft.Web>sites>app-name>config>authsettingsV2。
請選取 ,再編輯。
新增一個包含
domain_hint項目的loginParameters陣列:"identityProviders": { "azureActiveDirectory": { "login": { "loginParameters": ["domain_hint=<domain-name>"], } } }選取 [PUT]。
此設定會將 domain_hint 查詢字串參數附加至登入重新導向 URL。
重要
用戶端可以在收到重新導向 URL 之後移除 domain_hint 參數,然後使用不同的網域登入。 因此,雖然此函式很方便,但不是安全性功能。
授權或拒絕使用者
App Service 會處理最簡單的授權案例,例如,拒絕未經驗證的要求。 您的應用程式可能需要更精細的授權行為,例如只限制特定使用者群組的存取權。
您可能需要撰寫自定義應用程式程式代碼,以允許或拒絕登入使用者的存取權。 在某些情況下,App Service 或識別提供者或許可以協助您,而不需要變更程式碼。
伺服器層級 (僅限 Windows 應用程式)
針對任何 Windows 應用程式,您可以編輯 web.config 檔案來定義 IIS 網頁伺服器的授權行為。 Linux 應用程式不使用 IIS,且無法透過 web.config進行設定。
若要移至應用程式的 Kudu 偵錯控制台,請選取 [開發工具進階工具>],然後選取 [移至]。 然後選取 [ 偵錯控制台]。
您也可以使用此 URL 開啟此頁面:
https://<app-name>-<random-hash>.scm.<region>.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專案,只允許存取您組織中的使用者。 如需詳細資訊,請參閱 管理 OAuth 用戶端。
應用程式層級
如果其他層級中的任何一個未提供您所需的授權,或者您的平臺或身份提供者不受支援,您必須撰寫自定義程式碼,以便根據使用者宣告來授權使用者。