探索 App Service 中的驗證與授權
Azure App Service 提供內建驗證和授權支援。 您可以在 Web 應用程式、RESTful API 或 Azure Functions 中撰寫最少的程式碼或完全不撰寫程式碼，以登入使用者並存取資料。
為何要使用內建驗證？
您不必使用 App Service 進行驗證及授權。 許多 Web 架構都有附帶安全性功能，您可以選擇是否要使用這些功能。 相較於 App Service 提供的彈性，若您需要更多彈性，也可以寫入自己的公用程式。
App Service 和 Azure Functions 的內建驗證功能提供同盟識別提供者的現成驗證，讓您專注於應用程式的其餘部分，可節省時間和精力。
- Azure App Service 可讓您將各種驗證功能整合到 Web 應用程式或 API 中，而不需自行實作。
- 驗證直接內建於平台中，不需要任何特定語言、SDK、安全性專業知識或程式碼。
- 您可以整合多個登入提供者。 例如，Microsoft Entra ID、Facebook、Google、X。
身分識別提供者
App Service 使用同盟身分識別，由第三方識別提供者為您管理使用者身分識別和驗證流程。 預設可用的識別提供者如下：
| Provider | 登入端點 | 做法指引 |
|---|---|---|
| Microsoft 身分識別平台 | /.auth/login/aad |
App Service Microsoft 身分識別平台登入 |
/.auth/login/facebook |
App Service Facebook 登入 | |
/.auth/login/google |
App Service Google 登入 | |
| X | /.auth/login/twitter |
App Service X 登入 |
| 任何 OpenID Connect 提供者 | /.auth/login/<providerName> |
App Service OpenID Connect 登入 |
| GitHub | /.auth/login/github |
App Service GitHub 登入 |
當您透過上述其中一個提供者啟用驗證及授權，可使用其登入端點進行使用者驗證，及驗證來自提供者的驗證權杖。 您可以為使用者提供不限數量的上述登入選項。
運作方式
驗證和授權模組會在與應用程式程式碼相同的沙箱中執行。 啟用時，每個傳入的 HTTP 要求都會通過該模組，然後才會交由您的應用程式程式碼進行處理。 這個模組可為您的應用程式處理下列事項：
- 使用指定的識別提供者驗證使用者和用戶端
- 驗證、儲存及重新整理已設定的識別提供者所簽發的 OAuth 權杖
- 管理已驗證的工作階段
- 將身分識別資訊插入 HTTP 要求標頭
模組會與應用程式程式碼分開執行，而且可以使用 Azure Resource Manager 設定或使用設定檔進行設定。 無需 SDK、特定程式設計語言或變更應用程式程式碼。
注意
在 Linux 和容器中，驗證和授權模組會在與應用程式程式碼隔離的個別容器中執行。 因為不執行內含式，所以無法直接與特定的語言架構相整合。
驗證流程
所有提供者的驗證流程皆相同，差別僅在是否要使用提供者的 SDK 登入。
不使用提供者 SDK：應用程式會將同盟登入委派給 App Service。 瀏覽器應用程式通常就是這種委派方式，可以將提供者的登入頁面呈現給使用者。 伺服器程式碼管理登入流程，稱為伺服器導向式流程或伺服器流程。
使用提供者 SDK：應用程式會手動將使用者登入至提供者，然後將驗證權杖提交給 App Service 進行驗證。 通常來說無瀏覽器應用程式皆是如此，其無法向使用者展示提供者登入頁面。 應用程式程式碼管理登入流程，稱為用戶端導向式流程或用戶端流程。 這適用於 REST API、Azure Functions、JavaScript 瀏覽器用戶端，以及使用提供者 SDK 登入使用者的原生行動應用程式。
下表顯示驗證流程的步驟。
| Step | 不使用提供者 SDK | 使用提供者 SDK |
|---|---|---|
| 將使用者登入 | 將用戶端重新導向至 /.auth/login/<provider>。 |
用戶端程式碼可使用提供者 SDK 直接將使用者登入，及接收驗證權杖。 如需相關資訊，請參閱提供者文件。 |
| 後續驗證 | 提供者可將用戶端重新導向至 /.auth/login/<provider>/callback。 |
用戶端程式碼會將提供者的權杖提供給 /.auth/login/<provider> 來進行驗證。 |
| 建立已驗證的工作階段 | App Service 會新增已驗證的 Cookie 來進行回應。 | App Service 會將自己的驗證權杖傳回給用戶端程式碼。 |
| 提供已驗證的內容 | 用戶端會在後續要求中包含驗證 Cookie (瀏覽器會自動處理)。 | 用戶端程式碼會展示 X-ZUMO-AUTH 標頭中的驗證權杖 (由 Mobile Apps 用戶端 SDK 自動處理)。 |
針對用戶端瀏覽器，App Service 可以自動將所有未驗證的使用者導向 /.auth/login/<provider>。 您也可以使用其選擇的提供者，向使用者展示一或多個可登入您應用程式的 /.auth/login/<provider> 連結。
授權行為
在 Azure 入口網站中，您可以設定 App Service 在傳入要求未通過驗證時的許多行為。
允許未經驗證的要求：這個選項會延遲授權流向您應用程式程式碼的未經驗證流量。 針對已驗證的要求，App Service 也會在 HTTP 標頭中傳遞驗證資訊。 此選項會提供更大的彈性來處理匿名要求。 此選項可讓您向使用者顯示多個登入提供者。
需要驗證：此選項會拒絕應用程式的任何未經驗證流量。 此拒絕可以是重新導向到已設定識別提供者之一的動作。 在這些情況下，瀏覽器用戶端會被重新導向至您選擇的提供者
/.auth/login/<provider>。 如果匿名要求來自原生行動應用程式，則傳回的回應會是HTTP 401 Unauthorized。 您也可以將此拒絕設定為所有要求的HTTP 401 Unauthorized或HTTP 403 Forbidden。警告
以這種方式限制存取，適用於對您應用程式的所有呼叫，不建議需要公開可用首頁的應用程式 (如許多單頁應用程式) 這麼做。
權杖存放區
App Service 提供內建的權杖存放區，這是與 Web 應用程式、API 或原生行動應用程式的使用者相關聯的權杖存放庫。 當您啟用任何提供者的驗證時，應用程式會立即使用此權杖存放區。
記錄和追蹤
如果您啟用應用程式記錄，則會直接在記錄檔中收集驗證和授權追蹤。 如果您看到未預期的驗證錯誤，則可以在現有的應用程式記錄檔中尋找所有詳細資料。