Azure Container Apps 中的驗證和授權

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

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

為何要使用內建驗證?

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

Container Apps 的內建驗證功能可藉由為同盟識別提供者提供現成的驗證來節省您的時間和精力,讓您專注于應用程式的其餘部分。

  • Azure Container Apps 可讓您存取各種內建驗證提供者。
  • 內建的驗證功能不需要任何特定的語言、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 連線 提供者 /.auth/login/<providerName> OpenID Connect

當您使用其中一個提供者時,登入端點可用於提供者的使用者驗證和驗證權杖驗證。 您可以為使用者提供任意數目的這些提供者選項。

使用內建驗證的考慮

這項功能應該只能與 HTTPS 搭配使用。 請確定 allowInsecure 已停用容器應用程式的輸入組態。

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

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

功能架構

驗證和授權中介軟體元件是平臺的功能,可在應用程式中的每個複本上以側車容器的形式執行。 啟用時,每個連入 HTTP 要求都會通過安全性層,再由您的應用程式處理。

An architecture diagram showing requests being intercepted by a sidecar container which interacts with identity providers before allowing traffic to the app container

平臺中介軟體會為您應用程式處理數件事:

  • 使用指定的識別提供者驗證使用者和用戶端
  • 管理已驗證的工作階段
  • 將身分識別資訊插入 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 UnauthorizedHTTP 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_tokenrefresh_tokenexpires_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":"<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

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

注意

不同的語言架構可能會以不同的格式將這些標頭呈現給應用程式程式碼,例如小寫或標題大小寫。

下一步

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