Azure 容器應用程式提供內建的驗證與授權功能 (有時稱為「Easy Auth」),可用最少或不需撰寫程式碼即可保護啟用外部輸入的容器應用程式。
如需驗證與授權的詳細資訊,請參閱您所選提供者的下列指南。
為何要使用內建驗證?
您不需要使用這項功能來進行驗證與授權。 您可以使用所選 Web 架構中隨附的安全性功能,或自行撰寫實用程式。 然而,為驗證 (讓使用者登入) 與授權 (提供存取受保護資料的權限) 建立安全的解決方案可能需要大量心力。 您必須確保遵循產業最佳做法與標準,並使您的實作隨時保持最新。
適用於容器應用程式的內建驗證功能可透過提供與聯合身分識別提供者的開箱即用驗證來節省您的時間與精力。 這些功能可讓您將更多時間專注於開發應用程式,而減少建立安全系統的時間。
好處包括:
- Azure 容器應用程式提供多種內建驗證提供者的存取。
- 內建驗證功能不需要任何特定語言、SDK、安全性專業知識,甚至不需要您撰寫任何程式碼。
- 您可以整合多個提供者,包括 Microsoft Entra ID、Facebook、Google 和 X。
附註
Azure 容器應用程式使用與 Azure App Service 相同的驗證和授權系統。 如需驗證和授權的詳細資訊,請參閱 Azure App Service 和 Azure Functions 中的驗證和授權。
Azure 容器應用程式在 App Service 之間實作授權和驗證的方式有一些差異。 本文的內容詳細介紹了重要的差異。
識別提供者
容器應用程式使用聯合身分識別,其中由協力廠商身分識別提供者為您管理使用者身分與驗證流程。 預設可使用下列識別提供者:
| 提供者 | 登入端點 | 做法指引 |
|---|---|---|
| Microsoft 身分識別平台 | /.auth/login/aad |
Microsoft 身分識別平台 |
/.auth/login/facebook |
||
| GitHub | /.auth/login/github |
GitHub |
/.auth/login/google |
||
| X | /.auth/login/x |
X |
| 任何 OpenID Connect 提供者 | /.auth/login/<providerName> |
OpenID 連線 |
當您使用這些提供者之一時,登入端點可用於使用者驗證與來自提供者的驗證詞元驗證。 您可以為使用者提供任意數量的這些提供者選項。
使用內建驗證的考量
此功能應僅搭配 HTTPS 使用。 請確保您的容器應用程式輸入控制器組態中 allowInsecure 已停用。
您可以將容器應用程式設定為使用驗證,無論是否限制存取網站內容與 API。 若要將應用程式存取限制為僅允許經過驗證的使用者,請將其限制存取設定為需要驗證。 若要啟用驗證但不限制存取,請將其限制存取設定為允許未驗證存取。
根據預設,每個容器應用程式會發出其自己的唯一 Cookie 或詞元來進行驗證。 您也可以提供自己的簽署與加密金鑰。
功能架構
驗證與授權中介軟體元件是一項平台功能,以 Sidecar 容器的形式在應用程式中的每個複本上執行。 啟用後,在每個傳入 HTTP 要求通過安全層之後,您的應用程式便會處理該要求。
平台中介軟體會為您的應用程式處理數個事項:
- 使用指定的識別提供者驗證使用者和用戶端
- 管理已驗證的工作階段
- 將身分識別資訊插入 HTTP 要求標頭
驗證與授權模組在一個獨立的容器中執行,與您的應用程式程式碼相互隔離。 由於安全性容器不是在程序內執行,因此無法與特定語言架構進行直接整合。 然而,如本文所述,應用程式所需的相關資訊會以要求標頭的方式提供。
驗證流程
所有提供者的驗證流程相同,但會因您是否希望使用提供者的 SDK 進行登入而有所不同:
不使用提供者 SDK (伺服器導向流程或伺服器流程):應用程式將聯合登入委派給容器應用程式。 委派通常發生在瀏覽器應用程式中,瀏覽器會向使用者呈現提供者的登入頁面。
使用提供者 SDK (用戶端導向流程或用戶端流程):應用程式會手動讓使用者登入提供者,然後將驗證詞元提交給容器應用程式以進行驗證。 此方法通常用於不會向使用者呈現提供者登入頁面的無瀏覽器應用程式。 例如原生行動應用程式會使用提供者的 SDK 為使用者登入。
在容器應用程式中,受信任的瀏覽器應用程式呼叫容器應用程式中的另一個 REST API 時,可以使用伺服器導向流程進行驗證。 如需更多資訊,請參閱自訂登入與登出。
資料表顯示了驗證流程的步驟。
| 步驟 | 不使用提供者 SDK | 使用提供者 SDK |
|---|---|---|
| 1. 使用者登入 | 將用戶端重新導向至 /.auth/login/<PROVIDER>。 |
用戶端程式碼可使用提供者 SDK 直接將使用者登入,及接收驗證權杖。 如需相關資訊,請參閱提供者文件。 |
| 2. 登入後階段 | 提供者可將用戶端重新導向至 /.auth/login/<PROVIDER>/callback。 |
用戶端程式碼將提供者的詞元張貼至 /.auth/login/<PROVIDER> 以進行驗證。 |
| 3. 建立驗證的工作階段 | 容器應用程式會在回應中新增驗證 Cookie。 | 容器應用程式會將其自己的驗證詞元傳回給用戶端程式碼。 |
| 4. 提供已驗證的內容 | 用戶端會在後續要求中包含驗證 Cookie (瀏覽器會自動處理)。 | 用戶端程式碼會在 X-ZUMO-AUTH 標頭中提供驗證詞元。 |
對於用戶端瀏覽器,容器應用程式可以自動將所有未驗證的使用者導向 /.auth/login/<PROVIDER>。 您也可以使用其選擇的提供者,向使用者展示一或多個可登入您應用程式的 /.auth/login/<PROVIDER> 連結。
授權行為
在 Azure 入口網站中,您可以編輯容器應用程式的驗證設定,以針對未驗證的傳入要求設定各種行為。 以下標題說明了各選項。
允許未驗證存取:此選項會將未驗證流量的授權延後到您的應用程式程式碼處理。 對於已驗證的要求,容器應用程式也會在 HTTP 標頭中傳遞驗證資訊。 您的應用程式可以使用標頭中的資訊來為要求做出授權決策。
此選項在處理匿名要求時提供更高的彈性。 例如,它可讓您向使用者呈現多個登入提供者。 不過,您必須撰寫程式碼。
需要驗證:此選項會拒絕所有未驗證的應用程式流量。 此拒絕可以是重新導向到已設定識別提供者之一的動作。 在這些情況下,瀏覽器用戶端會被重新導向至您選擇的提供者
/.auth/login/<PROVIDER>。 如果匿名要求來自原生行動應用程式,則傳回的回應會是HTTP 401 Unauthorized。 您也可以將此拒絕設定為所有要求的HTTP 401 Unauthorized或HTTP 403 Forbidden。使用此選項時,您不需要在應用程式中撰寫任何驗證程式碼。 更細部的授權,例如角色特定授權,可透過檢查使用者宣告來處理 (請參閱存取使用者宣告)。
注意
限制存取您的應用程式會套用至所有發往您應用程式的要求。 這些限制可能不適用於具有公開網頁的應用程式,這在許多單頁式應用程式中相當常見。
附註
根據預設,您 Microsoft Entra 租用戶中的任何使用者都可以向 Microsoft Entra ID 請求您的應用程式的詞元。 如果您想要將應用程式的存取限制為一組定義的使用者,則可以在 Microsoft Entra ID 中設定應用程式。
自訂登入與登出
容器應用程式驗證提供內建的登入與登出端點。啟用此功能後,這些端點會位於您容器應用程式的 /.auth 路由首碼之下。
使用多個登入提供者
入口網站組態不提供讓使用者呈現多個登入提供者 (例如同時使用 Facebook 和 X) 的一鍵式方式。 然而,將此功能新增至您的應用程式並不困難。 步驟概述如下:
首先,在 Azure 入口網站的驗證 / 授權頁面中,設定您想啟用的每個身分識別提供者。
在要求未經驗證時要採取的動作 中,選取允許匿名要求 (不採取動作)。
在登入頁面、導覽列或應用程式中的任何其他位置,為您啟用的每個提供者新增一個登入連結 (/.auth/login/<provider>)。 例如:
<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</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>
當使用者選取其中一個連結時,會向使用者顯示對應提供者的 UI。
警告
對於用戶端應用程式,用戶端的路由管理器可能會攔截 /.auth/login/ 路由,使驗證 Sidecar 無法接收要求。 請確保您的用戶端路由組態允許伺服器處理這些路由。
若要在登入後將使用者重新導向至自訂 URL,請使用 post_login_redirect_uri 查詢字串參數 (不要與您身分識別提供者組態中的 Redirect URI 混淆)。 例如,若要在登入後將使用者導向 /Home/Index,請使用下列 HTML 程式碼:
<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>
用戶端導向登入
在用戶端導向登入中,應用程式會使用提供者專屬的 SDK 讓使用者登入身分識別提供者。 接著,應用程式程式碼會使用 HTTP POST 要求將產生的驗證詞元提交給容器應用程式以進行驗證 (請參閱驗證流程)。
要驗證提供者詞元,容器應用程式必須先以所需的提供者進行設定。 在執行階段,從提供者取得驗證詞元後,將詞元張貼至 /.auth/login/<provider> 以進行驗證。 例如:
POST https://<hostname>.azurecontainerapps.io/.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 屬性為選用。 向 Live 服務請求詞元時,請務必請求 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>"} |
|
如果提供者的詞元驗證成功,API 會在回應主體中傳回 authenticationToken,這就是您的工作階段詞元。
{
"authenticationToken": "...",
"user": {
"userId": "sid:..."
}
}
取得此工作階段詞元後,您可以透過在 HTTP 請求中加入 X-ZUMO-AUTH 標頭來存取受保護的應用程式資源。 例如:
GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>
登出工作階段
使用者可以透過向應用程式的 /.auth/logout 端點發送 GET 請求來登出。
GET 請求會執行以下操作:
- 清除目前工作階段的驗證 Cookie。
- 刪除目前使用者在詞元存放區中的詞元。
- 對 Microsoft Entra ID 和 Google 的身分提供者執行伺服器端登出。
以下是在網頁中的簡單登出連結:
<a href="/.auth/logout">Sign out</a>
預設情況下,成功登出會將用戶端重新導向至 URL /.auth/logout/done。 您可以透過新增 post_logout_redirect_uri 查詢參數來變更登出後的重新導向頁面。 例如:
GET /.auth/logout?post_logout_redirect_uri=/index.html
請確保對 post_logout_redirect_uri 的值進行編碼。
使用完整 URL 時,URL 必須托管在相同網域下。
在應用程式程式碼中存取使用者聲明
對於所有語言框架,Container Apps 會將進入詞元中的聲明提供給您的應用程式程式碼。 這些聲明會注入到請求標頭中,無論是來自已驗證的終端使用者或用戶端應用程式,標頭都會存在。 外部請求無法設定這些標頭,因此只有 Container Apps 設定時才會存在。 一些範例標頭包括:
X-MS-CLIENT-PRINCIPAL-NAMEX-MS-CLIENT-PRINCIPAL-ID
任何語言或框架撰寫的程式碼都可以從這些標頭中取得所需資訊。
附註
不同語言框架可能以不同格式呈現這些標頭給應用程式程式碼,例如小寫或標題大小寫。
使用 EasyAuth 建立安全端點
在使用 Azure Container Apps 認證保護端點時,你需要用 Microsoft Entra ID 註冊應用程式並設定認證設定。
請依照以下步驟設定安全存取:
建立 Azure AD 應用程式註冊
az ad app create \ --display-name <APP_DISPLAY_NAME> \ --sign-in-audience AzureADMyOrg ---啟用應用程式來發放 ID 令牌。 此步驟是 Easy Auth 支援所必需的。
az ad app update \ --id <APPLICATION_ID> \ --enable-id-token-issuance true新增 Easy Auth 回呼的重新導向 URI。
az ad app update \ --id <APP_ID> \ --web-redirect-uris "https://<APP-NAME>.<ENVIRONMENT-NAME>.<REGION>.azurecontainerapps.io/.auth/login/aad/callback" ---產生用戶端密碼
az ad app credential reset \ --id <APP_ID>" \ --display-name "<APP_NAME>-Secret" ---為您的應用程式建立服務主體名稱。
az ad sp create --id <APP_ID> ---設定你的容器應用程式使用Microsoft Entra ID認證。
確保你給
<APP_NAME>佔位符的值是你設定支援 EasyAuth 的應用程式名稱。az containerapp auth microsoft update \ --name <APP_NAME> \ --resource-group <RESOURCE_GROUP> \ --client-id <APP_ID> \ --client-secret CLIENT_SECRET> \ --tenant-id <TENANT_ID> \ --yes
後續步驟
請參考以下文章了解如何保護您的容器應用程式。