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

Azure App 服務 提供內建的驗證和授權功能（有時稱為「輕鬆驗證」），因此您可以在 Web 應用程式、RESTful API 和行動後端撰寫最少或沒有程式代碼來登入使用者及存取數據，以及Azure Functions。 本文說明 App Service 如何協助簡化應用程式的驗證和授權。

為何要使用內建驗證？

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

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

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

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

身分識別提供者

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

當您使用其中一個提供者設定這項功能時，其登入端點可用於用戶驗證，以及驗證來自提供者的驗證令牌。 您可以為使用者提供不限數量的上述登入選項。

使用內建驗證的考慮

啟用這項功能會導致應用程式的所有要求自動重新導向至 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，可以使用伺服器導向流程進行驗證。 如需詳細資訊，請參閱 自定義登入和註銷。

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

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

授權行為

在 Azure 入口網站 中，您可以在未驗證連入要求時，使用許多行為來設定 App Service。 下列標題描述選項。

Restric 存取

• 允許未經驗證的要求 這個選項會將未經驗證流量的授權延遲至您的應用程式程式碼。 針對已驗證的要求，App Service 也會在 HTTP 標頭中傳遞驗證資訊。

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

• 需要驗證 這個選項會拒絕應用程式的任何未驗證流量。 [未驗證的要求] 區段中會指定要採取的特定動作。

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

  警告

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

  注意

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

未經驗證的要求

• HTTP 302 找到重新導向：建議網站 將動作重新導向至其中一個已設定的識別提供者。 在這些情況下，瀏覽器用戶端會被重新導向至您選擇的提供者 /.auth/login/<provider>。
• HTTP 401 未經授權：如果匿名要求來自原生行動應用程式，則 傳回的回應為 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 的模組參考。

使用 Azure Front Door 時的考慮

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

1. 停用驗證工作流程的快取

   請參閱 停用驗證工作流程 的快取，以深入瞭解如何在 Azure Front Door 中設定規則，以停用驗證和授權相關頁面的快取。

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

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

3. 確定 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 標頭。

   其他反向 Proxy，例如 Azure 應用程式閘道 或第三方產品可能會使用不同的標頭，而且需要不同的 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 以遵守 X-Forwarded-Host Azure Front Door 所使用的標頭。

   匯入設定

   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 服務 上執行的 Web 應用程式
• 教學課程：在 Azure App 服務 中驗證和授權使用者端對端 （Windows 或 Linux）
• Azure AppService EasyAuth 的 .NET Core 整合 （第三方）
• 使用 .NET Core 取得 Azure App 服務 驗證（第三方）