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

注意

從 2024 年 6 月 1 日起，所有新建立的 App Service 應用程式都可以選擇使用命名慣例 <app-name>-<random-hash>.<region>.azurewebsites.net 來產生唯一的預設主機名稱。 現有的應用程式名稱將保持不變。

範例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

如需詳細資料，請參閱 App Service 資源的唯一預設主機名稱 (英文)。

Azure App Service 提供內建的驗證和授權功能 (有時稱為"Easy Auth")，因此，您在 Web 應用程式、RESTful API 和行動裝置後端，以及 Azure Functions 中，幾乎不需要撰寫或完全無需撰寫程式碼，即可登入使用者並存取資料。 本文說明 App Service 如何協助您簡化應用程式的驗證和授權。

為何要使用內建驗證？

您不需要使用此功能便可以進行驗證和授權。 您可以在選擇的 Web 架構中使用配套的安全性功能，也可以撰寫自己的公用程式。 不過，您必須確保自己的解決方案隨時保有最新的安全性、通訊協定和瀏覽器更新。

針對驗證 (登入使用者) 和授權 (提供安全資料的存取權) 實作安全解決方案，可能需要付出重大努力。 您必須確定能遵循業界最佳做法和標準，並讓您的實作保持最新狀態。 App Service 和 Azure Functions 的內建驗證功能提供同盟識別提供者的現成驗證，讓您專注於應用程式的其餘部分，可節省時間和精力。

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

您的應用程式可能需要支援更複雜的案例，例如 Visual Studio 整合或累加同意。 有數種不同的驗證解決方案可支援這些案例。 若要深入瞭解，請參閱身分識別案例。

身分識別提供者

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

Provider	登入端點	做法指引
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 連線傳輸任何安全性權杖。

App Service 可在不限制對您網站內容和 API 之存取的情況下用於驗證。 您可以在 Web 應用程式的 [驗證]>[驗證設定] 區段中設定存取限制。 若要將應用程式存取僅限於已驗證的使用者，請設定 [當要求未經驗證時所要採取的動作]，以使用其中一個已設定的識別提供者來登入。 若要驗證但不限制存取，請將 [當要求未經驗證時所要採取的動作] 設定為 [允許匿名要求 (無動作)]。

重要

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

運作方式

功能架構

驗證流程

授權行為

權杖存放區

記錄和追蹤

功能架構

驗證和授權中介軟體元件是在與應用程式相同的 VM 上執行的平台功能。 啟用此功能時，每個傳入的 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 的呼叫。 如需詳細資訊，請參閱自訂登入和登出。

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

Step	不使用提供者 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 找到重新導向: 建議用於網站 將動作重新導向至其中一個已設定的識別提供者。 在這些情況下，瀏覽器用戶端會被重新導向至您選擇的提供者 /.auth/login/<provider>。
• HTTP 401 未經授權: 建議用於 API 如果匿名要求來自原生行動應用程式，則傳回的回應是 HTTP 401 Unauthorized。 您也可以將拒絕設定為針對所有要求傳回 HTTP 401 Unauthorized。
• HTTP 403 禁止 針對所有要求將拒絕設定為 HTTP 403 Forbidden。
• HTTP 404 找不到 針對所有要求將拒絕設定為 HTTP 404 Not found。

權杖存放區

App Service 提供內建的權杖存放區，這是與 Web 應用程式、API 或原生行動應用程式的使用者相關聯的權杖存放庫。 當您啟用任何提供者的驗證時，應用程式會立即使用此權杖存放區。 如果應用程式程式碼需要代表使用者存取這些提供者的資料，例如：

• 張貼至已驗證使用者的 Facebook 時間軸
• 使用 Microsoft Graph API 讀取使用者的公司資料

您通常必須撰寫程式碼，才能在應用程式中收集、儲存及重新整理這些權杖。 使用權杖存放區時，您只有在需要權杖時才會取出權杖，並在權杖失效時才會告知 App Service 加以重新整理。

系統會針對已驗證的工作階段快取識別碼權杖、存取權杖和重新整理權杖，而且只有相關聯的使用者能存取這些權杖。

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

記錄和追蹤

如果您啟用應用程式記錄，則會直接在記錄檔中看到驗證和授權追蹤。 如果您看到未預期的驗證錯誤，則可以在現有的應用程式記錄檔中尋找所有詳細資料。 如果您啟用失敗要求追蹤，就可以看到驗證和授權模組可能在失敗要求中所扮演的確切角色。 在追蹤記錄中，尋找名為 EasyAuthModule_32/64 的模組參考。

跨網站要求偽造風險降低

App Service 驗證可藉由檢查用戶端要求，以降低 CSRF 的下列條件：

• 這是使用會話 Cookie 進行驗證的 POST 要求。
• 要求來自已知的瀏覽器（由 HTTP User-Agent 標頭決定）。
• HTTP 或 HTTP Origin Referer 標頭遺失，或不在已設定的外部網域清單中進行重新導向。
• HTTP Origin 標頭遺失，或不在已設定的 CORS 來源清單中。

當要求滿足所有這些條件時，App Service 驗證會自動拒絕它。 您可以將外部網域新增至 [驗證>編輯驗證設定>允許的外部重新導向 URL]，以因應此緩和邏輯。

使用 Azure Front Door 時的考量

使用 Azure App 服務 搭配 Azure Front Door 或其他反向 Proxy 的驗證時，必須考慮一些其他事項。

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

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

  透過 Azure Front Door 公開時，通常無法直接存取 App Service。 例如，透過 Azure Front Door Premium 中的 Private Link 公開 App Service，即可防止這種情況。 若要防止驗證工作流程直接將流量重新導向回 App Service，請務必設定應用程式重新導向回 https://<front-door-endpoint>/.auth/login/<provider>/callback。

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

  在某些設定中，App Service 會使用 App Service FQDN 作為重新導向 URI，而不是 Front Door FQDN。 這會導致將用戶端重新導向至 App Service 而不是 Front Door 時發生問題。 若要變更該項目，forwardProxy 設定需要設定為 Standard，以讓 App Service 遵守 Azure Front Door 所設定的 X-Forwarded-Host 標頭。

  Azure 應用程式閘道或協力廠商產品這類其他反向 Proxy 可能會使用不同的標頭，而且需要不同的 forwardProxy 設定。

  此設定目前無法透過 Azure 入口網站完成，而且需要透過 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 Functions 應用程式設定為使用 Microsoft Entra 登入
• 自訂登入和登出

• 使用 OAuth 權杖和工作階段
• 存取使用者和應用程式宣告
• 以檔案為基礎的設定

範例：

• 教學課程：將驗證新增至在 Azure App Service 上執行的 Web 應用程式
• 教學課程：在 Azure App Service 中端對端驗證和授權使用者 (Windows 或 Linux)
• Azure AppService EasyAuth 的 .NET Core 整合 (協力廠商) (英文)
• 使 Azure App Service 驗證得以搭配 .NET Core 運作 (協力廠商) (英文)