Azure Container Apps 中的驗證和授權

Azure Container Apps 提供內建的驗證和授權功能（有時稱為「簡易驗證」），以最少或沒有任何程式代碼保護您的外部輸入啟用的容器應用程式。

如需驗證和授權的詳細數據，請參閱下列指南，以取得您選擇的提供者。

• Microsoft Entra ID
• Facebook
• GitHub
• Google
• Twitter
• 自訂 OpenID 連線

為何要使用內建驗證？

您不需要使用此功能便可以進行驗證和授權。 您可以在選擇的 Web 架構中使用配套的安全性功能，也可以撰寫自己的公用程式。 不過，實作安全的解決方案以進行驗證（登入使用者）和授權（提供安全數據的存取權）可能會花費大量精力。 您必須務必遵循業界最佳做法和標準，並讓您的實作保持在最新狀態。

Container Apps 的內建驗證功能可藉由為同盟識別提供者提供現成的驗證來節省時間和精力。 這些功能可讓您將更多時間放在開發應用程式，以及建置安全性系統的時間較少。

這些好處包括：

• Azure 容器應用程式可讓您存取各種內建驗證提供者。
• 內建的驗證功能不需要任何特定語言、SDK、安全性專業知識，甚至不需要您撰寫任何程式碼。
• 您可以與多個提供者整合，包括 Microsoft Entra ID、Facebook、Google 和 Twitter。

身分識別提供者

Container Apps 會使用 同盟身分識別，其中第三方識別提供者會為您管理使用者身分識別和驗證流程。 預設可用的識別提供者如下：

Provider	登入端點	做法指引
Microsoft 身分識別平台	/.auth/login/aad	Microsoft 身分識別平台
Facebook	/.auth/login/facebook	Facebook
GitHub	/.auth/login/github	GitHub
Google	/.auth/login/google	Google
Twitter	/.auth/login/twitter	Twitter
任何 OpenID Connect 提供者	/.auth/login/<providerName>	OpenID Connect

當您使用上述其中一個提供者，就可使用登入端點進行使用者驗證，及驗證來自提供者的驗證權杖。 您可以為使用者提供不限數量的提供者選項。

使用內建驗證的考量

這項功能應該只能與 HTTPS 搭配使用。 確定在容器應用程式的輸入設定中停用 allowInsecure。

您可以設定容器應用程式進行驗證，無論是否限制存取網站內容和 API。 若僅要將應用程式存取限制為已驗證的使用者，請將其 [限制存取] 設定設為 [需要驗證]。 若要驗證但不限制存取，請將其 [限制存取] 設定設為 [允許未驗證的存取]。

根據預設，每個容器應用程式都會發出自己的唯一 Cookie 或令牌來進行驗證。 您也可以提供自己的簽署和加密金鑰。

功能架構

驗證和授權中介軟體元件是平台的功能，可在應用程式中的每個複本上以 sidecar 容器的形式執行。 啟用時，您的應用程式會在通過安全性層之後處理每個傳入的 HTTP 要求。

平台中介軟體可為您的應用程式處理下列事項：

• 使用指定的識別提供者驗證使用者和用戶端
• 管理已驗證的工作階段
• 將身分識別資訊插入 HTTP 要求標頭

驗證和授權模組會在與您應用程式程式碼隔離的個別容器中執行。 因為安全性容器不執行內含式，所以無法直接與特定的語言架構相整合。 不過，您的應用程式所需的相關信息會在要求標頭中提供，如本文所述。

驗證流程

所有提供者的驗證流程皆相同，差別僅在是否要使用提供者的 SDK 登入：

• 如果沒有提供者 SDK （伺服器導向流程 或 伺服器流程）：應用程式會將同盟登入委派給 Container Apps。 委派通常是瀏覽器應用程式的情況，其無法向使用者展示提供者登入頁面。

• 使用提供者 SDK（用戶端導向流程或用戶端流程）：應用程式會手動將使用者登入提供者，然後將驗證令牌提交至 Container Apps 以進行驗證。 此方法通常是無瀏覽器應用程式的情況，其無法向使用者展示提供者登入頁面。 例如，使用提供者的 SDK 讓使用者登入的原生行動應用程式。

您可以從 Container Apps 中信任的瀏覽器應用程式呼叫到 Container Apps 中的另一個 REST API，可以使用伺服器導向流程進行驗證。 如需詳細資訊，請參閱 自定義登入和註銷。

下表顯示驗證流程的步驟。

Step	不使用提供者 SDK	使用提供者 SDK
1.將使用者登入	將用戶端重新導向至 /.auth/login/<PROVIDER>。	用戶端程式碼可使用提供者 SDK 直接將使用者登入，及接收驗證權杖。 如需相關資訊，請參閱提供者文件。
2.後續驗證	提供者可將用戶端重新導向至 /.auth/login/<PROVIDER>/callback。	用戶端程式碼會將提供者的權杖公佈至 /.auth/login/<PROVIDER> 以進行驗證。
3.建立已驗證的工作階段	Container Apps 會將已驗證的 Cookie 新增至回應。	Container Apps 會將自己的驗證令牌傳回至客戶端程序代碼。
4.提供已驗證的內容	用戶端會在後續要求中包含驗證 Cookie (瀏覽器會自動處理)。	用戶端程式碼會在 X-ZUMO-AUTH 標頭中顯示驗證權杖。

針對客戶覽器，Container Apps 可以自動將所有未經驗證的使用者導向至 /.auth/login/<PROVIDER>。 您也可以使用其選擇的提供者，向使用者展示一或多個可登入您應用程式的 /.auth/login/<PROVIDER> 連結。

授權行為

在 Azure 入口網站 中，您可以編輯容器應用程式的驗證設定，以在傳入要求未通過驗證時以各種行為進行設定。 下列標題會說明可用選項。

• 允許未經驗證的存取：此選項會將未經驗證流量的授權延遲到您的應用程式程序代碼。 針對已驗證的要求，Container Apps 也會傳遞 HTTP 標頭中的驗證資訊。 您的應用程式可以使用標頭中的資訊來決定要求的授權決策。

  此選項會提供更大的彈性來處理匿名要求。 例如，它可讓您向使用者顯示多個登入提供者。 不過，您必須撰寫程式碼。

• 需要驗證：此選項會拒絕應用程式的任何未經驗證流量。 此拒絕可以是重新導向到已設定識別提供者之一的動作。 在這些情況下，瀏覽器用戶端會被重新導向至您選擇的提供者 /.auth/login/<PROVIDER>。 如果匿名要求來自原生行動應用程式，則傳回的回應會是 HTTP 401 Unauthorized。 您也可以將此拒絕設定為所有要求的 HTTP 401 Unauthorized 或 HTTP 403 Forbidden。

  使用此選項時，您不需要在應用程式中撰寫任何驗證程式碼。 您可以藉由檢查使用者的宣告來處理更精細的授權 (例如特定角色授權，請參閱存取使用者宣告)。

  警告

  以這種方式限制存取，適用於對您應用程式的所有呼叫，不建議需要公開可用首頁的應用程式 (如許多單頁應用程式) 這麼做。

  注意

  根據預設，Microsoft Entra 租使用者中的任何使用者都可以從 Microsoft Entra 識別碼要求應用程式的令牌。 如果您想要將應用程式的存取限制為一組定義的使用者，則可以在 Microsoft Entra ID 中設定應用程式。

自定義登入和註銷

Container Apps 驗證提供用於登入和註銷的內建端點。啟用此功能時，這些端點可在容器應用程式的路由前置詞下 /.auth 取得。

使用多個登入提供者

入口網站設定不會提供周全的方式，向您的使用者顯示多個登入提供者 (例如 Facebook 和 Twitter)。 不過，要將功能新增至您的應用程式並不困難。 步驟概述如下：

首先，在 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/twitter">Log in with Twitter</a>

當用戶選取其中一個連結時，會向用戶顯示個別提供者的UI。

若要將登入後的使用者重新導向至自訂 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 要求，將產生的驗證令牌提交至 Container Apps 進行驗證（請參閱 驗證流程）。

若要驗證提供者令牌，必須先使用所需的提供者來設定容器應用程式。 在執行階段，在您從提供者擷取驗證權杖之後，請將權杖公佈到 /.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 是選用屬性。 從即時服務要求權杖時，請一律要求 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":"<ACCES_TOKEN_SECRET>"}

如果提供者權杖驗證成功，API 會連同 authenticationToken 在回應本文中一起傳回，這是您的工作階段權杖。

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

在取得此工作階段權杖之後，您可以藉由將 X-ZUMO-AUTH 標頭新增至 HTTP 要求，來存取受保護的應用程式資源。 例如：

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

登出工作階段

用戶可以將要求傳送 GET 至應用程式的 /.auth/logout 端點來註銷。 要求 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-NAME
• X-MS-CLIENT-PRINCIPAL-ID

以任何語言或架構撰寫的程式碼可以從這些標頭中取得所需的資訊。

注意

這些應用程式程式碼的標題可能會因不同的語言架構，而以不同的格式呈現，例如小寫或標題字體。

下一步

如需保護容器應用程式的詳細資訊，請參閱下列文章。

• Microsoft Entra ID
• Facebook
• GitHub
• Google
• Twitter
• 自訂 OpenID 連線