Azure 容器應用程式中的驗證與授權

Azure 容器應用程式提供內建驗證和授權功能 (有時稱為「簡易驗證」)，以最少或無程式碼方式保護您的外部輸入啟用容器應用程式。

如需有關驗證和授權的詳細資訊，請針對您選擇的提供者參閱下列指南。

• Microsoft Entra ID
• Facebook
• GitHub
• Google
• X
• 自訂 OpenID Connect

為何要使用內建驗證？

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

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

這些好處包括：

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

身分識別提供者

容器應用程式使用同盟身分識別，由第三方識別提供者為您管理使用者身分識別和驗證流程。 預設可用的識別提供者如下：

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

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

使用內建驗證的考量

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

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

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

功能架構

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

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

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

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

驗證流程

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

• 不使用提供者 SDK (伺服器導向流程或伺服器流程)：應用程式會將同盟登入委派給容器應用程式。 委派通常是瀏覽器應用程式的情況，其無法向使用者展示提供者登入頁面。

• 使用提供者 SDK (用戶端導向的流量或用戶端流量)：應用程式會以手動方式將使用者登入提供者，然後將驗證權杖提交給 App Service 進行驗證。 此方法通常是無瀏覽器應用程式的情況，其無法向使用者展示提供者登入頁面。 例如，使用提供者的 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 中設定應用程式。

自定義登入和註銷

Container Apps 驗證提供用於登入和註銷的內建端點。啟用此功能時，這些端點可在容器應用程式的路由前置詞下 /.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。

若要將登入後的使用者重新導向至自訂 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 要求，將產生的驗證權杖提交給容器應用程式來驗證 (請參閱驗證流程)。

若要驗證提供者權杖，容器應用程式必須先以所需的提供者進行設定。 在執行階段，在您從提供者擷取驗證權杖之後，請將權杖公佈到 /.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 必須裝載在相同的網域中。

存取應用程式程式碼中的使用者宣告

針對所有語言架構，容器應用程式會讓傳入權杖中的宣告可用於您的應用程式程式碼。 宣告會插入要求標頭中，無論是來自已驗證的使用者還是用戶端應用程式。 外部要求不得設定這些標頭，因此僅在由容器應用程式設定時，這些標頭才會出現。 某些範例標頭包括︰

• X-MS-CLIENT-PRINCIPAL-NAME
• X-MS-CLIENT-PRINCIPAL-ID

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

注意

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

下一步

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

• Microsoft Entra ID
• Facebook
• GitHub
• Google
• X
• 自訂 OpenID Connect