操作說明：從 Azure 存取控制服務遷移
警告
本內容適用於較舊的 Azure AD v1.0 端點。 將 Microsoft 身分識別平台用於新專案。
Microsoft Azure 存取控制服務 (ACS) 是 Azure Active Directory (Azure AD) 的一項服務，將於 2018 年 11 月 7 日淘汰。 目前使用存取控制的應用程式和服務，必須在淘汰前完全移轉到其他驗證機制。 本文說明給目前客戶的建議移轉選項，協助您規劃汰換存取控制的事宜。 如果您目前未使用存取控制，不需要採取任何動作。
概觀
存取控制是雲端驗證服務，能以簡單的方式驗證和授權使用者，使其得以存取您的 Web 應用程式和服務。 它讓您不需要考慮您的程式碼也能享有許多驗證和授權功能。 存取控制的主要使用者包括 Microsoft .NET 用戶端、ASP.NET Web 應用程式及 Windows Communication Foundation (WCF) Web 服務的開發人員和架構設計師。
存取控制的使用案例可以分成三個主要類別：
- 驗證特定的 Microsoft 雲端服務，包括 Azure 服務匯流排和 Dynamics CRM。 用戶端應用程式可以從存取控制取得權杖，用來驗證這些服務以執行各種動作。
- 新增驗證方式至自訂和預先封裝 (如 SharePoint) 的 Web 應用程式。 透過存取控制的「被動」驗證方式，Web 應用程式支援以 Microsoft 帳戶 (前身為 Live ID)，以及 Google、Facebook、Yahoo、Azure AD 及 Active Directory 同盟服務 (AD FS) 等帳戶進行單一登入。
- 使用存取控制簽發的權杖保護自訂 Web 服務。 透過「主動」驗證方式，Web 服務可確保惟有通過存取控制之驗證的已知用戶端能存取自身服務。
每個使用案例及其建議的移轉策略會在後續各節中討論。
警告
在大部分情況下，將現有應用程式和服務移轉至較新的技術需要大幅變更程式碼。 建議您立即開始規劃及執行移轉作業，以避免任何可能的中斷或停機。
存取控制包含下列元件：
- 安全權杖服務 (STS)，可接收驗證要求然後簽發安全性權杖。
- Azure 傳統入口網站，用以建立、刪除、啟用及停用存取控制的命名空間。
- 個別的存取控制管理入口網站，用以自訂及設定存取控制命名空間。
- 管理服務，用以自動化入口網站功能。
- 權杖轉換規則引擎，用以定義複雜邏輯以控制存取控制簽發之權杖的輸出格式。
若要使用這些元件，您必須建立一或多個存取控制命名空間。 「命名空間」是應用程式和服務進行通訊的專用存取控制執行個體。 命名空間會與其他所有存取控制客戶隔離。 其他存取控制客戶會使用他們自己的命名空間。 存取控制中的命名空間有專用 URL，看起來像這樣：
https://<mynamespace>.accesscontrol.windows.net
與 STS 和管理作業的所有通訊都透過此 URL 完成。 不同的路徑有不同的用途。 若要判斷應用程式和服務是否使用存取控制，請監視所有進入 https://<namespace>.accesscontrol.windows.net 的流量。 所有進入該 URL 的流量都由存取控制處理，而且必須停止。
但所有進入 https://accounts.accesscontrol.windows.net 的流量除外。 進入此 URL 的流量已經由其他服務處理，因此不受「存取控制」的淘汰影響。
如需有關存取控制的詳細資訊，請參閱存取控制服務 2.0 (已封存)。
找出哪些應用程式會受影響
遵循這一節中的步驟，找出哪些應用程式會受到 ACS 淘汰影響。
下載並安裝 ACS PowerShell
移至 PowerShell 資源庫並下載 Acs.Namespaces。
藉由執行來安裝模組
Install-Module -Name Acs.Namespaces藉由執行來取得所有可能的命令
Get-Command -Module Acs.Namespaces若要取得特定命令的說明，請執行：
Get-Help [Command-Name] -Full其中
[Command-Name]是 ACS 命令的名稱。
列出您的 ACS 命名空間
使用 Connect-AcsAccount Cmdlet 連線至 ACS。
您可能需要先執行
Set-ExecutionPolicy -ExecutionPolicy Bypass，才可以執行命令，而且成為這些訂用帳戶的管理員才能執行命令。使用 Get-AcsSubscription Cmdlet 列出可用的 Azure 訂用帳戶。
使用 Get-AcsNamespace Cmdlet 列出您的 ACS 命名空間。
檢查哪些應用程式會受影響
使用上一個步驟中的命名空間並移至
https://<namespace>.accesscontrol.windows.net例如，如果其中一個命名空間是 contoso-test，請移至
https://contoso-test.accesscontrol.windows.net在 [信任關係] 之下，選取 [信賴憑證者應用程式] 以查看會受 ACS 淘汰影響的應用程式清單。
針對您擁有的任何其他 ACS 命名空間重複步驟 1-2。
淘汰排程
截至 2017 年 11 月止，所有存取控制元件均完全受到支援且可運作。 唯一的限制是您不能透過 Azure 傳統入口網站建立新的存取控制命名空間。
以下是存取控制元件的淘汰排程：
- 2017 年 11 月：Azure 傳統入口網站中的 Azure AD 管理員體驗已淘汰。 目前，可在以下新的專用 URL 進行「存取控制」的命名空間管理：
https://manage.windowsazure.com?restoreClassic=true。 該 URL 可以用來檢視現有的命名空間、啟用和停用命名空間，若您有需要，也可以刪除命名空間。 - 2018 年 4 月 2 日：Azure 傳統入口網站已完全淘汰，這意謂著透過任何 URL 都無法進行「存取控制」命名空間管理。 屆時，您將無法停用或啟用、刪除或列舉存取控制命名空間。 不過，「存取控制」管理入口網站將會在
https://<namespace>.accesscontrol.windows.net運作並提供完整功能。 存取控制的其他所有元件都將繼續正常運作。 - 2018 年 11 月 7 日：所有「存取控制」元件將永久關閉。 這包括存取控制管理入口網站、管理服務、STS 和權杖轉換規則引擎。 此時，傳送給存取控制 (位於
<namespace>.accesscontrol.windows.net) 的任何要求都會失敗。 在那之前，請確實將所有現有的應用程式和服務移轉至其他技術。
注意
原則會停用在一段期間內未要求權杖的命名空間。 自 2018 年 9 月起，這段期間目前為 14 天的非使用狀態，但在未來的幾週內，這將縮短成 7 天的非使用狀態。 如果您有目前停用的「存取控制」命名空間，您可以下載並安裝 ACS PowerShell 來重新啟用這些命名空間。
移轉策略
下列各節說明從存取控制移轉到其他 Microsoft 技術的初略建議。
Microsoft 雲端服務的用戶端
接受存取控制簽發之權杖的每項 Microsoft 雲端服務，現在支援至少一個其他驗證方式。 每項服務適合的驗證機制不盡相同。 建議您參閱每項服務的特定文件，了解官方指導。 為了方便起見，以下提供每一組文件：
| 服務 | 指引 |
|---|---|
| Azure 服務匯流排 | 移轉至共用存取簽章 |
| Azure 服務匯流排轉送 | 移轉至共用存取簽章 |
| Azure 受控快取 | 遷移至 Azure Cache for Redis |
| Azure DataMarket | 遷移至 Azure AI 服務 API |
| BizTalk 服務 | 移轉至 Azure App Service 的邏輯應用程式功能 |
| Azure 媒體服務 | 移轉至 Azure AD 驗證 |
| Azure 備份 | 升級 Azure 備份代理程式 |
SharePoint 客戶
SharePoint 2013、2016 和 SharePoint Online 客戶已長期使用 ACS 在雲端、內部部署及混合式案例中進行驗證。 有些 SharePoint 功能和使用案例將會受到 ACS 淘汰影響，有些則不會。 下表針對一些利用 ACS 的最常用 SharePoint 功能，摘要說明移轉指導方針：
| 功能 | 指引 |
|---|---|
| 從 Azure AD 驗證使用者 | 先前，Azure AD 並不支援 SharePoint 進行驗證所需的 SAML 1.1 權杖，因此 ACS 被用來作為讓 SharePoint 與 Azure AD 權杖格式相容的媒介。 現在，您可以在內部部署應用程式上使用 Azure AD 應用程式庫 SharePoint 將 SharePoint 直接連線到 Azure AD。 |
| 應用程式驗證 & SharePoint 內部部署中的伺服器對伺服器驗證 | 不受 ACS 淘汰影響；無須進行任何變更。 |
| SharePoint 增益集 (提供者裝載和 SharePoint 裝載) 的低信任度授權 | 不受 ACS 淘汰影響；無須進行任何變更。 |
| SharePoint 雲端混合式搜尋 | 不受 ACS 淘汰影響；無須進行任何變更。 |
使用被動驗證的 Web 應用程式
存取控制針對使用存取控制進行使用者驗證的 Web 應用程式，提供下列功能給 Web 應用程式開發人員和架構設計師使用：
- 與 Windows Identity Foundation (WIF) 深入整合。
- 與 Google、Facebook、Yahoo、Azure Active Directory、AD FS 帳戶及 Microsoft 帳戶建立同盟。
- 支援下列驗證通訊協定：OAuth 2.0 Draft 13、WS-Trust 及 Web 服務同盟 (WS-同盟)。
- 支援下列權杖格式：JSON Web 權杖 (JWT)、SAML 1.1、SAML 2.0 和簡單 Web 權杖 (SWT)。
- 整合至 WIF 的首頁領域探索體驗，可以讓使用者選擇用來登入的帳戶類型。 這項體驗由 Web 應用程式裝載並且可完全自訂。
- 權杖轉換可以讓您對 Web 應用程式從存取控制收到的宣告進行多種自訂設定，包括：
- 從識別提供者傳遞宣告。
- 新增額外的自訂宣告。
- 在某些情況下，可以使用簡單的 if-then 邏輯簽發宣告。
很抱歉，目前尚未有提供以上所有同等功能的服務。 您應該評估您需要 存取控制 的功能，然後選擇使用 Microsoft Entra 標識碼、Azure Active Directory B2C (Azure AD B2C) 或其他雲端驗證服務。
遷移至 Microsoft Entra標識碼
要考慮的路徑是直接將應用程式和服務與 Microsoft Entra標識元整合。 Microsoft Entra 識別碼是 Microsoft 公司或學校帳戶的雲端式識別提供者。 Microsoft Entra 識別碼是 Microsoft 365、Azure 等等的識別提供者。 它提供與存取控制類似的同盟驗證功能，但是僅支援部分存取控制功能。
主要範例是與社交識別提供者的同盟，例如 Facebook、Google 和 Yahoo。 如果您的使用者使用這些類型的認證登入，Microsoft Entra標識元不是您的解決方案。
Microsoft Entra識別碼也不一定支援與 存取控制 完全相同的驗證通訊協定。 例如，雖然 存取控制 和 Microsoft Entra 標識碼都支援 OAuth，但每個實作之間會有細微的差異。 在移轉時，不同的實作會需要您修改程式碼。
不過，Microsoft Entra標識碼提供數個可能的優點給 存取控制 客戶。 它能以原生方式支援雲端裝載的 Microsoft 工作或學校帳戶，而這些帳戶的使用者通常是存取控制客戶。
Microsoft Entra 租使用者也可以透過AD FS與一或多個 內部部署的 Active Directory 實例同盟。 這樣一來，您的應用程式便能驗證雲端式使用者和內部部署裝載的使用者。 它也支援 WS-同盟通訊協定，讓使用 WIF 的 Web 應用程式整合作業變得相對簡單。
下表比較與 Web 應用程式相關的 存取控制 功能，以及可在 Microsoft Entra 識別碼中使用的功能。
概括而言，如果您只讓使用者使用他們的 Microsoft 公司或學校帳戶登入，Microsoft Entra 標識符可能是您移轉的最佳選擇。
| 功能 | 存取控制支援 | Microsoft Entra標識碼支援 |
|---|---|---|
| 帳戶類型 | ||
| Microsoft 工作或學校帳戶 | 支援 | 支援 |
| Windows Server Active Directory 和 AD FS 的帳戶 | - 透過與 Microsoft Entra 租使用者同盟支援 - 與 AD FS 建立直接同盟則可支援 |
僅透過與 Microsoft Entra 租使用者同盟支援 |
| 其他企業身分識別管理系統的帳戶 | - 可以透過與 Microsoft Entra 租使用者同盟 - 建立直接同盟則可支援 |
可以透過與 Microsoft Entra 租使用者同盟 |
| 個人用 Microsoft 帳戶 | 支援 | 透過 Microsoft Entra v2.0 OAuth 通訊協定支援，但無法透過任何其他通訊協議支援 |
| Facebook、Google、Yahoo 帳戶 | 支援 | 無法經由任何方式提供支援 |
| 通訊協定與 SDK 相容性 | ||
| WIF | 支援 | 支援，但是提供的指示有限 |
| WS-同盟 | 支援 | 支援 |
| OAuth 2.0 | 支援 Draft 13 | 支援 RFC 6749 (最新型的規格) |
| WS-Trust | 支援 | 不支援 |
| 權杖格式 | ||
| JWT | 在搶鮮版 (Beta) 中支援 | 支援 |
| SAML 1.1 | 支援 | 預覽 |
| SAML 2.0 | 支援 | 支援 |
| SWT | 支援 | 不支援 |
| 自訂 | ||
| 可自訂的首頁領域探索/帳戶挑選 UI | 可下載的程式碼，可以納入應用程式 | 不支援 |
| 上傳自訂權杖簽署憑證 | 支援 | 支援 |
| 在權杖中自訂宣告 | - 從識別提供者傳遞輸入宣告 - 從識別提供者取得宣告形式的存取權杖 - 根據輸入宣告值簽發輸出宣告 - 簽發具有常數值的輸出宣告 |
- 無法從同盟識別提供者傳遞宣告 - 無法從識別提供者取得宣告形式的存取權杖 - 無法根據輸入宣告值簽發輸出宣告 - 可以簽發具有常數值的輸出宣告 - 可以根據同步處理至 Microsoft Entra 識別碼的使用者屬性發出輸出宣告 |
| 自動化 | ||
| 自動化設定和管理工作 | 使用存取控制管理服務則可支援 | 使用 Microsoft Graph API 則可支援 |
如果您決定 Microsoft Entra 識別碼是應用程式和服務的最佳移轉路徑，您應該注意兩種方式來整合您的應用程式與 Microsoft Entra 標識符。
若要使用 WS-Federation 或 WIF 與 Microsoft Entra 識別元整合，建議您遵循為非資源庫應用程式設定同盟單一登錄中所述的方法。 本文指的是為 SAML 型單一登錄設定 Microsoft Entra 標識符，但也適用於設定 WS-Federation。 遵循此方法需要 Microsoft Entra標識碼 P1 或 P2 授權。 此方法有兩個優點：
- 您可以取得 Microsoft Entra 令牌自定義的完整彈性。 您可以自定義 Microsoft Entra 識別碼所發出的宣告，以符合由 存取控制 發出的宣告。 尤以使用者識別碼或名稱識別碼宣告最為重要。 若要在變更技術之後繼續收到使用者一致的使用者標識符，請確定 Microsoft Entra標識碼所簽發的使用者標識碼符合 存取控制 所發出的標識符。
- 您可以為您的應用程式設定專用的權杖簽署憑證與存留期。
注意
此方法需要 Microsoft Entra標識碼 P1 或 P2 授權。 如果您是存取控制客戶，而且需要 Premium 授權來為應用程式設定單一登入，請與我們連絡。 我們很樂意提供開發人員授權予您使用。
另一個方法是參考此程式碼範例，當中的 WS-同盟設定指示稍有不同。 此程式碼範例不使用 WIF，而是使用 ASP.NET 4.5 OWIN 中介軟體。 不過，應用程式註冊的指示適用於使用 WIF 的應用程式，而且不需要 Microsoft Entra 標識碼 P1 或 P2 授權。
如果您選擇此方法，您必須瞭解 Microsoft Entra 識別碼中的簽署金鑰變換。 此方法會使用 Microsoft Entra 全域簽署密鑰來發行令牌。 根據預設，WIF 不會自動重新整理簽署金鑰。 當 Microsoft Entra 標識符輪替其全域簽署密鑰時，您的 WIF 實作必須準備好接受變更。 如需詳細資訊，請參閱 Microsoft Entra標識符中簽署密鑰變換的重要資訊。
如果您可以透過OpenID Connect或 OAuth 通訊協定與 Microsoft Entra標識元整合，建議您這麼做。 我們在 Microsoft Entra 開發人員指南中提供有關如何將 Microsoft Entra 標識元整合到 Web 應用程式中的廣泛檔和指引。
移轉至 Azure Active Directory B2C
要考量的其他移轉路徑是 Azure AD B2C。 Azure AD B2C 是雲端驗證服務，就像存取控制一樣，可讓開發人員將其驗證和身分識別管理邏輯外包給雲端服務。 它是付費服務 (有免費和進階層)，專為作用中使用者多達數百萬的取用者互動應用程式而設計。
就像存取控制一樣，Azure AD B2C 其中一個最具吸引力的功能是支援許多不同類型的帳戶。 有了 Azure AD B2C，您可以讓使用者用 Microsoft 帳戶或 Facebook、Google、LinkedIn、GitHub 或 Yahoo 等帳戶登入。 Azure AD B2C 還支援「本機帳戶」，或使用者特別為您應用程式建立的使用者名稱與密碼。 Azure AD B2C 還提供豐富的擴充性供您自訂登入流程。
不過，Azure AD B2C 無法支援存取控制客戶可能需要的各種驗證通訊協定和權杖格式。 您也不能使用 Azure AD B2C 從識別提供者、Microsoft 等取得權杖，以及查詢使用者的其他相關資訊。
下表比較存取控制的 Web 應用程式相關功能，以及 Azure AD B2C 的同等功能。 在高階中，如果您的應用程式是針對取用者，或者如果它支援不同類型的帳戶，則 Azure AD B2C 對於您的移轉可能是正確的選擇。
| 功能 | 存取控制支援 | Azure AD B2C 支援 |
|---|---|---|
| 帳戶類型 | ||
| Microsoft 工作或學校帳戶 | 支援 | 透過自訂原則支援 |
| Windows Server Active Directory 和 AD FS 的帳戶 | 與 AD FS 建立直接同盟則可支援 | 以自訂原則建立 SAML 同盟則可支援 |
| 其他企業身分識別管理系統的帳戶 | 透過 WS-同盟建立直接同盟則可支援 | 以自訂原則建立 SAML 同盟則可支援 |
| 個人用 Microsoft 帳戶 | 支援 | 支援 |
| Facebook、Google、Yahoo 帳戶 | 支援 | 原生支援 Facebook 和 Google，Yahoo 則是透過自訂原則建立 OpenID Connect 同盟則可支援 |
| 通訊協定與 SDK 相容性 | ||
| Windows Identity Foundation (WIF) | 支援 | 不支援 |
| WS-同盟 | 支援 | 不支援 |
| OAuth 2.0 | 支援 Draft 13 | 支援 RFC 6749 (最新型的規格) |
| WS-Trust | 支援 | 不支援 |
| 權杖格式 | ||
| JWT | 在搶鮮版 (Beta) 中支援 | 支援 |
| SAML 1.1 | 支援 | 不支援 |
| SAML 2.0 | 支援 | 不支援 |
| SWT | 支援 | 不支援 |
| 自訂 | ||
| 可自訂的首頁領域探索/帳戶挑選 UI | 可下載的程式碼，可以納入應用程式 | 透過自訂 CSS 可完全自訂 UI |
| 上傳自訂權杖簽署憑證 | 支援 | 支援透過自訂原則自訂簽署金鑰 (非憑證) |
| 在權杖中自訂宣告 | - 從識別提供者傳遞輸入宣告 - 從識別提供者取得宣告形式的存取權杖 - 根據輸入宣告值簽發輸出宣告 - 簽發具有常數值的輸出宣告 |
- 可以從識別提供者傳遞宣告；某些宣告需有自訂原則 - 無法從識別提供者取得宣告形式的存取權杖 - 可以透過自訂原則根據輸入宣告值簽發輸出宣告 - 可以透過自訂原則簽發具有常數值的輸出宣告 |
| 自動化 | ||
| 自動化設定和管理工作 | 使用存取控制管理服務則可支援 | - 允許使用 Microsoft Graph API 來建立使用者 - 無法以程式設計方式建立 B2C 租用戶、應用程式或原則 |
如果您決定 Azure AD B2C 是適合您應用程式和服務的移轉方式，請先了解下列資源的內容：
移轉至 Ping Identity 或 Auth0
在某些情況下，您可能會發現 Microsoft Entra標識元和 Azure AD B2C 不足以取代 Web 應用程式中的 存取控制，而不需要進行重大程式碼變更。 幾個常見的範例可能包括：
- 使用 WIF 或 WS-同盟來以 Google，或 Facebook 等社交識別提供者登入的 Web 應用程式。
- 透過 WS-同盟通訊協定與企業識別提供者執行直接同盟的 Web 應用程式。
- 要求社交識別提供者 (例如 Google 或 Facebook) 所簽發之存取權杖，必須以宣告形式儲存於由存取控制所簽發之權杖中的 Web 應用程式。
- 具有 Microsoft Entra 識別碼或 Azure AD B2C 之複雜令牌轉換規則的 Web 應用程式無法重現。
- 使用 ACS 來集中管理與許多不同識別提供者之同盟的多租用戶 Web 應用程式
在這些情況下，您可能會想考慮將 Web 應用程式移轉至另一個雲端驗證服務。 我們建議您探索下列選項。 以下每個選項均提供類似存取控制的功能：
Auth0 是彈性的雲端識別服務，不僅建立了適用於存取控制客戶的高階移轉指南，而且幾乎能支援 ACS 支援的所有功能。
Ping Identity 提供兩種類似 ACS 的解決方案。 PingOne 是支援許多與 ACS 相同之功能的雲端識別服務，而 PingFederate 則是類似的內部部署身分識別產品，不過彈性更大。 如需有關使用這些產品的詳細資料，請參閱 Ping 的 ACS 淘汰指導。
我們與 Ping Identity 和 Auth0 合作的目的是，確保所有存取控制客戶都能獲得從存取控制中，盡可能簡單地搬移其應用程式和服務的移轉方式。
使用主動驗證的 Web 服務
存取控制針對受到存取控制簽發之權杖保護的 Web 服務，提供下列功能：
- 在您的存取控制命名空間中註冊一或多個服務識別。 使用服務識別要求權杖。
- 可透過使用下列類型的認證，來支援 OAuth WRAP 和 OAuth 2.0 Draft 13 通訊協定要求權杖：
- 為服務識別建立簡單密碼
- 使用對稱金鑰或 X509 憑證的已簽署 SWT
- 由受信任的識別提供者 (通常是 AD FS 執行個體) 簽發的 SAML 權杖
- 支援下列權杖格式：JWT、SAML 1.1、SAML 2.0 和 SWT。
- 簡單權杖轉換規則。
存取控制中的服務識別通常用於實作伺服器對伺服器驗證。
移轉至 Microsoft Entra 標識碼
我們針對這種驗證流程的建議是移轉至 Microsoft Entra標識碼。 Microsoft Entra 識別碼是 Microsoft 公司或學校帳戶的雲端式識別提供者。 Microsoft Entra 標識碼是 Microsoft 365、Azure 等的識別提供者。
您也可以使用 OAuth 用戶端認證授與的 Microsoft Entra 實作，針對伺服器對伺服器驗證使用 Microsoft Entra 標識符。 下表比較伺服器對伺服器驗證中 存取控制的功能，以及 Microsoft Entra 標識碼中可用的功能。
| 功能 | 存取控制支援 | Microsoft Entra標識碼支援 |
|---|---|---|
| 如何註冊 Web 服務 | 在存取控制管理入口網站中建立信賴憑證者 | 在 Azure 入口網站 中建立 Microsoft Entra Web 應用程式 |
| 如何註冊用戶端 | 在存取控制管理入口網站中建立服務識別 | 在 Azure 入口網站 中建立另一個 Microsoft Entra Web 應用程式 |
| 使用的通訊協定 | - OAuth WRAP 通訊協定 - 授與 OAuth 2.0 Draft 13 用戶端認證 |
OAuth 2.0 用戶端認證授與 |
| 用戶端驗證方法 | - 簡單密碼 - 已簽署的 SWT - 來自同盟識別提供者的 SAML 權杖 |
- 簡單密碼 - 已簽署的 JWT |
| 權杖格式 | - JWT - SAML 1.1 - SAML 2.0 - SWT |
僅限 JWT |
| 權杖轉換 | - 新增自訂宣告 - 簡單的 if-then 宣告簽發邏輯 |
新增自訂宣告 |
| 自動化設定和管理工作 | 使用存取控制管理服務則可支援 | 使用 Microsoft Graph API 則可支援 |
如需有關實作伺服器對伺服器案例的指導，請參閱下列資源：
移轉至 Ping Identity 或 Auth0
在某些情況下，您可能會發現 Microsoft Entra 客戶端認證和 OAuth 授與實作不足以取代架構中的 存取控制，而不需要變更主要程序代碼。 幾個常見的範例可能包括：
- 使用非 JWT 權杖格式的伺服器對伺服器驗證。
- 使用外部識別提供者提供之輸入權杖的伺服器對伺服器驗證。
- 具有令牌轉換規則的伺服器對伺服器驗證，Microsoft Entra 標識碼無法重現。
在這些情況下，您可能需考慮將 Web 應用程式移轉至另一個雲端驗證服務。 我們建議您探索下列選項。 以下每個選項均提供類似存取控制的功能：
Auth0 是彈性的雲端識別服務，不僅建立了適用於存取控制客戶的高階移轉指南，而且幾乎能支援 ACS 支援的所有功能。
Ping Identity 提供兩種類似 ACS 的解決方案。 PingOne 是支援許多與 ACS 相同之功能的雲端識別服務，而 PingFederate 則是類似的內部部署身分識別產品，不過彈性更大。 如需有關使用這些產品的詳細資料，請參閱 Ping 的 ACS 淘汰指導。
我們與 Ping Identity 和 Auth0 合作的目的是，確保所有存取控制客戶都能獲得從存取控制中，盡可能簡單地搬移其應用程式和服務的移轉方式。
傳遞驗證
針對含有任意權杖轉換的傳遞驗證，並沒有任何與 ACS 對等的 Microsoft 技術。 如果那是您客戶所需要的，Auth0 可能是最相近的近似解決方案。
問題、考量與意見反應
我們了解許多存取控制客戶在閱讀本文之後依然無法決定使用哪個的移轉方式。 您可能需要一些有助於判斷合適計劃的協助或指導。 如果想要討論您的移轉案例和問題，請在本頁面上留言。