Azure App Service 和 Azure Functions 中的驗證和授權

Azure App Service 提供內建的驗證 (登入使用者) 和授權 (提供安全資料的存取權) 功能。這些功能有時稱為「簡單驗證」。您可以使用這些功能來讓使用者登入並存取資料，方法是在 Web 應用程式、RESTful API、行動伺服器和函式 (部分機器翻譯) 中編寫一點程式碼，甚至完全不用編寫。

本文說明 App Service 如何協助您簡化應用程式的驗證和授權。

使用內建驗證的原因

若要實作驗證和授權，您可以使用所選 Web 架構中的配套安全性功能，也可以撰寫自己的工具。針對驗證和授權實作安全的解決方案可能需要付出巨大的努力。您需要遵循產業的最佳做法和標準。此外，也要確保自己的解決方案隨時套用最新的安全性、通訊協定和瀏覽器更新，以保持在最新狀態。

App Service 和 Azure Functions 的內建功能可透過提供搭配同盟識別提供者使用的現成驗證能力來節省您的時間與精力，讓您可以集中資源處理應用程式的其餘部分。

使用 App Service，您可以將驗證功能整合到 Web 應用程式或 API 中，而不需要自行實作。此功能直接內建於平台中，不需要使用任何特定語言、SDK、安全性專業知識或程式碼。您可以將其與多個登入提供者整合，例如 Microsoft Entra、Facebook、Google 和 X。

您的應用程式可能需要支援更複雜的案例，例如 Visual Studio 整合或累加同意。有數種驗證解決方案可用來支援這些案例。若要深入了解，請參閱驗證案例和建議 (部分機器翻譯)。

識別提供者

App Service 使用同盟身分識別 (英文)。 Microsoft 或非 Microsoft 識別提供者會為您管理使用者身分識別和驗證流程。預設可使用下列識別提供者：

提供者	登入端點	做法指引
Microsoft Entra	`/.auth/login/aad`	App Service Microsoft Entra 平台登入
Facebook	`/.auth/login/facebook`	App Service Facebook 登入 (部分機器翻譯)
Google	`/.auth/login/google`	App Service Google 登入 (部分機器翻譯)
X	`/.auth/login/x`	App Service X 登入 (部分機器翻譯)
GitHub	`/.auth/login/github`	App Service GitHub 登入 (部分機器翻譯)
Apple	`/.auth/login/apple`	透過 Apple 登入的 App Service 登入 (預覽) (部分機器翻譯)
任何 OpenID Connect 提供者	`/.auth/login/<providerName>`	App Service OpenID Connect 登入 (部分機器翻譯)

當您利用其中一個提供者設定此功能時，其登入端點即可用來驗證使用者，以及用來驗證提供者的驗證權杖。您可以為使用者提供這其中任意數目的登入選項。

使用內建驗證的考量

啟用內建驗證會導致對應用程式發出的所有要求都自動重新導向至 HTTPS，不論 App Service 設定是否設定為強制執行 HTTPS。您可以使用 V2 設定中的 requireHttps 設定，來停用此自動重新導向行為。不過，建議您繼續使用 HTTPS，並確保沒有任何安全性權杖透過不安全的 HTTP 連線進行傳輸。

無論是否有限制對網站內容和 API 的存取，您都可以使用 App Service 進行驗證。請在 Web 應用程式的 [設定]>[驗證]>[驗證設定] 區段中設定存取限制：

若要將應用程式存取權限制在僅經過驗證的使用者，請設定 [當要求未經驗證時所要採取的動作]，以使用所設定的其中一個識別提供者來進行登入。
若要進行驗證但不限制存取，請將 [當要求未經驗證時所要採取的動作] 設定為 [允許匿名要求 (無動作)]。

重要事項

您應該為每個應用程式註冊提供其自己的權限和同意。對不同的部署位置使用不同的應用程式註冊，以避免在環境之間共用權限。在測試新的程式碼時，這種做法有助於避免問題影響到生產應用程式。

運作方式

功能架構

驗證和授權中介軟體元件是在與應用程式相同的虛擬機器上執行的平台功能。當您啟用此元件時，每個傳入的 HTTP 要求都會先經過該元件，再由您的應用程式處理。

平台中介軟體會為您的應用程式處理數個事項：

使用指定的識別提供者驗證使用者和用戶端
驗證、儲存及重新整理已設定的識別提供者所發出的 OAuth 權杖
管理已驗證的工作階段
將身分識別資訊插入 HTTP 要求標頭

此模組會與您的應用程式程式碼分開執行。您可以使用 Azure Resource Manager 設定或使用設定檔 (部分機器翻譯) 來設定此模組。不需任何 SDK、特定的程式設計語言，或對應用程式程式碼進行任何變更。

Windows (非容器部署) 上的功能架構

驗證和授權模組會在與您應用程式相同的沙箱中執行原生的 IIS 模組。當您啟用此模組時，每個傳入的 HTTP 要求都會先經過該模組，再由您的應用程式處理。

Linux 和容器上的功能架構

驗證和授權模組會在與您應用程式的程式碼隔開的個別容器中執行。此模組會使用大使模式 (部分機器翻譯) 與傳入的流量互動，以執行與 Windows 上類似的功能。由於此模組不會在流程內執行，因此無法直接與特定語言架構整合。不過，您應用程式所需的相關資訊會在要求標頭中傳遞。

驗證流程

所有提供者的驗證流程都相同。區別在於您是否要使用提供者的 SDK 進行登入：

不使用提供者的 SDK：應用程式會將同盟登入委派給 App Service。這種委派通常出現在瀏覽器應用程式中，這些應用程式可以向使用者顯示提供者的登入頁面。伺服器程式碼會管理登入流程，因此也稱為「伺服器導向流程」或「伺服器流程」。

此案例適用於使用內嵌瀏覽器進行驗證的瀏覽器應用程式和行動應用程式。
使用提供者的 SDK：應用程式會手動將使用者登入到提供者內。然後，將驗證權杖提交給 App Service 進行驗證。這種流程通常出現在無瀏覽器應用程式中，這些應用程式無法向使用者顯示提供者的登入頁面。應用程式的程式碼會管理登入流程，因此也稱為「用戶端導向流程」或「用戶端流程」。

此案例適用於 REST API、Azure Functions (部分機器翻譯) 和 JavaScript 瀏覽器用戶端，以及登入流程需要更多彈性的瀏覽器應用程式。此案例也適用於使用提供者 SDK 讓使用者登入的原生行動應用程式。

您可以透過伺服器導向流程，來驗證從 App Service 中的信任瀏覽器應用程式對 App Service 或 Azure Functions (部分機器翻譯) 中另一個 REST API 的呼叫。如需詳細資訊，請參閱在 Azure App Service 驗證中自訂登入和登出。

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

步驟	不使用提供者 SDK	使用提供者 SDK
1. 讓使用者登入	提供者會將用戶端重新導向至 `/.auth/login/<provider>`。	用戶端程式碼會直接使用提供者的 SDK 讓使用者登入，並接收驗證權杖。如需詳細資訊，請參閱提供者的文件。
2. 進行後續驗證	提供者會將用戶端重新導向至 `/.auth/login/<provider>/callback`。	用戶端程式碼會將來自提供者的權杖張貼到 `/.auth/login/<provider>` 之中以進行驗證。
3. 建立已驗證的工作階段	App Service 會將已驗證的 Cookie 新增至回應。	App Service 會將自己的驗證權杖傳回給用戶端程式碼。
4. 提供已驗證的內容	用戶端在後續要求中包含驗證 Cookie (瀏覽器會自動處理)。	用戶端程式碼會在 `X-ZUMO-AUTH` 標頭中顯示驗證權杖。

對於用戶端瀏覽器，App Service 可以自動將所有未經驗證的使用者導向至 /.auth/login/<provider>。您也可以向使用者顯示一或多個 /.auth/login/<provider> 連結，讓其使用選擇的提供者登入到您的應用程式。

授權行為

在 Azure 入口網站中，您可以為 App Service 設定當傳入的要求未經驗證時的各種行為。下列各節會說明這些選項。

重要事項

預設情況下，此功能只會提供驗證，不會提供授權。除了您在這裡設定的任何檢查之外，您的應用程式可能仍然需要做出授權決策。

受限制的存取

允許未經驗證的要求：這個選項會將未經驗證之流量的授權作業延後，交由您的應用程式程式碼負責處理。對於已驗證的要求，App Service 也會在 HTTP 標頭中一起傳送驗證資訊。

此選項會提供更大的彈性來處理匿名要求。例如，它可讓您向使用者顯示多個登入提供者。不過，您必須撰寫程式碼。
需要驗證：此選項會拒絕應用程式的任何未經驗證流量。本文稍候的未經驗證的要求一節會指定要採取的特定動作。

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

注意

以這種方式限制存取適用於對您應用程式的所有呼叫，但對於希望有公開可用首頁的應用程式 (尤其是像許多單頁應用程式的情況) 來說，可能就不適合這麼做。如果需要例外狀況，您需要在設定檔中設定排除的路徑 (部分機器翻譯)。

附註

針對組織中的使用者使用 Microsoft 識別提供者時，預設行為是 Microsoft Entra 租用戶中的任何使用者皆可要求應用程式的權杖。如果您想要將對應用程式的存取限制為一組定義的使用者，您可以在 Microsoft Entra 中設定應用程式。 App Service 也提供一些基本的內建授權檢查，這些檢查可協助進行一些驗證。若要深入了解 Microsoft Entra 中的授權，請參閱 Microsoft Entra 授權基本概念。

未經驗證的要求

HTTP 302 Found 重新導向：建議用於網站：將動作重新導向至其中一個已設定的識別提供者。在這些情況下，系統會將瀏覽器用戶端重新導向至您所選提供者的 /.auth/login/<provider>。
HTTP 401 Unauthorized：建議用於 API：如果匿名要求來自原生行動應用程式，則傳回 HTTP 401 Unauthorized 回應。您也可以將所有要求的拒絕回應設定為 HTTP 401 Unauthorized。
HTTP 403 Forbidden：將所有要求的拒絕回應設定為 HTTP 403 Forbidden。
HTTP 404 Not found：將所有要求的拒絕回應設定為 HTTP 404 Not found。

權杖存放區

App Service 提供內建的權杖存放區。權杖存放區是與 Web 應用程式、API 或原生行動應用程式使用者相關聯之權杖的存放庫。當您使用任何提供者啟用驗證時，此權杖存放區就會立即供應用程式使用。

如果您的應用程式程式碼需要代表使用者存取這些提供者的資料，您通常必須撰寫程式碼以在應用程式中收集、儲存和重新整理這些權杖。動作可能包括：

張貼至已驗證使用者的 Facebook 動態時報。
使用 Microsoft Graph API 讀取使用者的公司資料。

使用權杖存放區時，您只有在需要權杖時才會取出權杖，並在權杖失效時才會告知 App Service 加以重新整理。

系統會快取已驗證工作階段的 ID 權杖、存取權杖和重新整理權杖。只有相關聯的使用者才能存取這些權杖。

如果您不需要在應用程式中使用權杖，則可以在應用程式的 [設定]>[驗證] 頁面上停用權杖存放區。

記錄和追蹤

如果您啟用應用程式記錄 (部分機器翻譯)，則驗證和授權的追蹤會直接顯示在記錄檔中。如果您看到非預期的驗證錯誤，可以在現有的應用程式記錄中查看，輕鬆找到所有詳細資料。

如果您啟用失敗要求追蹤 (部分機器翻譯)，就可以看到驗證和授權模組可能在失敗要求中扮演的確切角色。在追蹤記錄中，尋找名為 EasyAuthModule_32/64 的模組參考。

緩解跨網站偽造要求

App Service 驗證可藉由檢查用戶端要求是否符合以下條件，來緩解跨網站偽造要求：

其為透過工作階段 Cookie 進行驗證的 POST 要求。
要求來自已知瀏覽器，由 HTTP User-Agent 標頭決定。
HTTP Origin 或 HTTP Referer 標頭遺失，或不在已設定的已核准外部網域重新導向清單中。
HTTP Origin 標頭遺失，或不在已設定的 CORS 來源清單中。

當要求滿足以上所有條件時，App Service 驗證便會自動拒絕該要求。您可以在 [設定]>[驗證]>[編輯驗證設定]>[允許的外部重新導向 URL] 中，將外部網域新增至重新導向清單，以解決此緩解邏輯。

受保護的資源中繼資料（預覽）

App Service 可以提供 OAuth 2.0 受保護資源中繼資料，如 RFC 9728 (英文) 中所定義。這可協助 OAuth 2.0 用戶端瞭解如何與您的應用程式互動。這是模型環境定義通訊協定（MCP）伺服器授權的必要條件。

附註

受保護資源中繼資料的支援目前處於預覽階段，在功能正式推出之前，您設定它的方式可能會變更。

在預覽期間，您可以使用應用程式所需的逗號分隔範圍清單來設定 WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES應用程式設定，以啟用預設受保護的資源中繼資料文件。例如，當您讓 App Service 為您設定 Microsoft Entra 提供者時，它會設定類似 api://<client-id>/user_impersonation的範圍，取代 <client-id> 為應用程式註冊的實際用戶端識別碼。

預設受保護資源中繼資料文件包含下列內容：

房產	Description
`resource`	對應於存取受保護資源中繼資料的端點的資源 URI。
`authorization_servers`	您已設定之身分識別提供者的授權伺服器清單。
`scopes_supported`	您在應用程式設定中 `WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES` 指定的範圍清單。

使用預設組態時，不支援附加屬性。

設定預設受保護的資源中繼資料檔也會變更 App Service 處理 API 未經驗證要求的方式。當應用程式發出授權挑戰時，它會包含受保護資源中繼資料的 URL，然後用戶端可以擷取和處理這些中繼資料。挑戰也包括您在應用程式設定中 WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES 設定的範圍。

使用 Azure Front Door 的考量

當您在 Azure Front Door 或其他反向 Proxy 背後搭配使用 Azure App Service 與驗證時，請考慮下列動作。

停用 Azure Front Door 快取

停用驗證工作流程的 Azure Front Door 快取。

使用 Azure Front Door 端點進行重新導向

當 App Service 透過 Azure Front Door 公開時，通常無法直接存取 App Service。例如，您可以在 Azure Front Door 進階版中使用 Azure Private Link 來公開 App Service，以防止此行為。防止驗證工作流程將流量直接重新導向回 App Service。如需詳細資訊，請參閱重新導向 URI (部分機器翻譯)。

確定 App Service 使用正確的重新導向 URI

在某些設定中，App Service 會使用其完整網域名稱 (FQDN) 作為重新導向 URI，而非使用 Azure Front Door FQDN。當用戶端重新導向至 App Service 而非 Azure Front Door 時，此設定會導致問題。若要變更此設定，請將 forwardProxy 設定為 Standard，讓 App Service 遵循 Azure Front Door 設定的 X-Forwarded-Host 標頭。

其他反向 Proxy (例如 Azure 應用程式閘道或非 Microsoft 產品) 可能會使用不同的標頭，因此需要不同的 forwardProxy 設定。

您無法使用 Azure 入口網站來變更 forwardProxy 設定。您需要使用 az rest。

匯出設定

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

更新設定

搜尋：

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

請確定 convention 已設定為 Standard，以遵循 Azure Front Door 使用的 X-Forwarded-Host 標頭。

匯入設定

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

如需 App Service 驗證的詳細資訊，請參閱：

例如，請參閱：

快速入門：將應用程式驗證新增至在 Azure App Service 上執行的 Web 應用程式
教程：在 Azure App Service 中對使用者進行端對端驗證和授權
Azure App Service 簡單驗證的 .NET Core 整合 (英文) (非 Microsoft GitHub 內容)
讓 Azure App Service 驗證搭配 .NET Core 來運作 (英文) (非 Microsoft GitHub 內容)

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-11-06