驗證的新功能？
Microsoft 會定期新增和修改 Microsoft 身分識別平台 的特性和功能，以改善其安全性、可用性和標準合規性。
除非另有說明，否則此處所述的變更僅適用於在變更生效日期之後註冊的應用程式。
請定期查看這篇文章，以瞭解：
- 已知問題和修正
- 通訊協議變更
- 過時的功能
提示
若要收到此頁面更新的通知，請將此 URL 新增至 RSS 摘要讀取器：https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us
2023 年 10 月
已更新 Remote 連線 UX 提示
生效日期：2023年10月
受影響的端點：v2.0 和 v1.0
受影響的通訊協定：遠端 連線
Remote 連線 是一種跨裝置流程，用於涉及主要重新整理令牌的 Microsoft Authentication Broker 和 Microsoft Intune 相關案例。 為了協助防止網路釣魚攻擊，Remote 連線 流程將會收到更新的 UX 語言，以呼叫遠端裝置（起始流程的裝置）能夠在流程成功完成時存取貴組織使用的任何應用程式。
出現的提示看起來會像這樣：
2023 年 6 月
未驗證網域擁有者的電子郵件宣告遺漏
生效日期：2023年6月
受影響的端點：v2.0 和 v1.0
變更
針對 多租使用者應用程式，在令牌承載中要求選擇性 email 宣告時，預設會省略未驗證網域擁有者的電子郵件。
如果下列狀況，則會將電子郵件視為網域擁有者驗證：
- 網域屬於用戶帳戶所在的租使用者，而租用戶系統管理員已完成網域的驗證。
- 電子郵件來自 Microsoft 帳戶 （MSA）。
- 電子郵件來自Google帳戶。
- 電子郵件用於使用一次性密碼 （OTP） 流程進行驗證。
另請注意，Facebook 和 SAML/WS-Fed 帳戶沒有已驗證的網域。
2023 年 5 月
Power BI 系統管理員角色將會重新命名為 Fabric 管理員 istrator。
生效日期：2023年6月
受影響的端點：
- 列出 roleDefinitions - Microsoft Graph v1.0
- 列出 directoryRoles - Microsoft Graph v1.0
變更
Power BI 管理員 istrator 角色將會重新命名為 Fabric 管理員 istrator。
在 2023 年 5 月 23 日，Microsoft 推出了 Microsoft Fabric，其提供 Data Factory 所提供的數據整合體驗、Synapse 支持的數據工程、數據倉儲、數據科學，以及搭配 Power BI 的即時分析體驗和商業智慧 （BI），全都裝載在以湖為中心的 SaaS 解決方案上。 這些體驗的租使用者和容量管理會集中在 Fabric 管理員 入口網站中（先前稱為 Power BI 管理入口網站）。
從 2023 年 6 月開始，Power BI 管理員 istrator 角色將會重新命名為 Fabric 管理員 istrator，以配合此角色變更的範圍和責任。 所有應用程式，包括 Microsoft Entra ID、Microsoft Graph API、Microsoft 365 和 GDAP，都會在幾周內開始反映新的角色名稱。
提醒您，您的應用程式程式代碼和腳本不應該根據角色名稱或顯示名稱做出決策。
2021 年 12 月
AD FS 使用者會看到更多登入提示，以確保正確的使用者已登入。
生效日期：2021年12月
受影響的端點：整合式 Windows 驗證
受影響的通訊協定：整合式 Windows 驗證
變更
今天，當使用者傳送至AD FS進行驗證時，系統會以無訊息方式登入任何已經與AD FS會話的帳戶。 即使使用者打算登入不同的用戶帳戶，仍會發生無訊息登入。 若要降低發生這個不正確登入的頻率，從 12 月開始，如果 Windows 中的 Web 帳戶管理員在登入期間提供 Microsoft Entra 識別符login_hint，表示特定使用者需要登入，則會將 參數傳送prompt=login至 AD FS。
符合上述需求時（WAM 用來將使用者傳送至 Microsoft Entra ID 進行登入時， login_hint 會包含 ，而 使用者網域 prompt=login支援的 AD FS 實例則不會以無訊息方式登入，而是要求提供使用者名稱以繼續登入 AD FS。 如果他們想要登入現有的AD FS工作階段，他們可以選取登入提示下方顯示的 [繼續為目前使用者] 選項。 否則，他們可以繼續使用他們想要登入的用戶名稱。
這項變更將在 2021 年 12 月推出，並在幾周內推出。 它不會變更登入行為：
- 直接使用 IWA 的應用程式
- 使用 OAuth 的應用程式
- 未與 AD FS 實例同盟的網域
2021 年 10 月
錯誤 50105 已修正為在互動式驗證期間未傳回interaction_required
生效日期：2021年10月
受影響的端點：v2.0 和 v1.0
受影響的通訊協定：需要使用者指派之應用程式的 所有使用者流程
變更
當未指派的用戶嘗試登入系統管理員已標示為需要使用者指派的應用程式時，就會發出錯誤 50105（目前指定）。 這是常見的訪問控制模式，使用者通常必須找到系統管理員來要求指派以解除封鎖存取。 錯誤有一個錯誤，會導致正確處理 interaction_required 錯誤回應的妥善編碼應用程式中產生無限迴圈。 interaction_required 告知應用程式執行互動式驗證，但即使在執行這項操作之後，Microsoft Entra ID 仍會傳 interaction_required 回錯誤回應。
錯誤案例已更新，因此，在非互動式驗證期間（用來隱藏UX的位置 prompt=none ），系統會指示應用程式使用 interaction_required 錯誤回應執行互動式驗證。 在後續的互動式驗證中，Microsoft Entra ID 現在會保存使用者並直接顯示錯誤訊息，以防止循環發生。
提醒您，您的應用程式程式代碼不應該根據之類的 AADSTS50105錯誤碼字串做出決策。 相反地，請遵循我們的錯誤處理指引，並在回應的標準error欄位中使用標準化的驗證回應，例如 interaction_requiredlogin_required 和 。 其他回應欄位僅供人類針對其問題進行疑難解答。
您可以在錯誤查閱服務上檢閱 50105 錯誤的目前文字等等： https://login.microsoftonline.com/error?code=50105。
單一租用戶應用程式中的AppId URI需要使用預設配置或已驗證的網域
生效日期：2021年10月
受影響的端點：v2.0 和 v1.0
受影響的通訊協定：所有流程
變更
對於單一租使用者應用程式，新增或更新 AppId URI 會驗證 HTTPS 配置 URI 中的網域列在客戶租使用者中已驗證的網域清單中，或是值使用 Microsoft Entra ID 所提供的預設配置 （api://{appId}）。 如果網域不在已驗證的網域清單中，或值未使用預設配置，這可能會防止應用程式新增AppId URI。
若要尋找已驗證網域的詳細資訊，請參閱 自定義網域檔。
這項變更不會影響在其 AppID URI 中使用未驗證網域的現有應用程式。 它只會驗證新的應用程式，或當現有的應用程式更新標識碼 URI 或將新應用程式新增至 identifierUri 集合時。 新的限制僅適用於 2021 年 10 月 15 日之後新增至應用程式 identifierUris 集合的 URI。 當限制於 2021 年 10 月 15 日生效時，應用程式 identifierUris 集合中的 AppId URI 仍會繼續運作，即使您將新的 URI 新增至該集合也一樣。
如果要求驗證檢查失敗，建立/更新的應用程式 API 會傳回 400 badrequest 給指出 HostNameNotOnVerifiedDomain 的用戶端。
支援下列 API 和 HTTP 配置型應用程式識別碼 URI 格式。 請取代下表後面的清單中所述的佔位元值。
| 支援的應用程式識別碼 URI 格式 |
範例應用程式識別碼 URI |
|---|---|
| <api:// appId> | api://fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed |
| api://< tenantId/<appId>> | api://a8573488-ff46-450a-b09a-6eca0c6a02dc/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed |
| api://< tenantId>/<string> | api://a8573488-ff46-450a-b09a-6eca0c6a02dc/api |
| <api:// string>/<appId> | api://productapi/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed |
| <https:// tenantInitialDomain.onmicrosoft.com/>< string> | https://contoso.onmicrosoft.com/productsapi |
| <https:// verifiedCustomDomain>/<string> | https://contoso.com/productsapi |
| https://< string>。<verifiedCustomDomain> | https://product.contoso.com |
| https://< string>。<verifiedCustomDomain>/<string> | https://product.contoso.com/productsapi |
- <appId> - 應用程式物件的應用程式識別碼 （appId） 屬性。
- <string> - 主機或 API 路徑區段的字串值。
- <tenantId> - Azure 產生的 GUID，代表 Azure 內的租使用者。
- <tenantInitialDomain tenantInitialDomain.onmicrosoft.com>< - ，其中 <tenantInitialDomain>> 是租使用者建立者在租使用者建立時指定的初始功能變數名稱。
- <verifiedCustomDomain> - 為 Microsoft Entra 租使用者設定的已驗證自定義網域 。
注意
如果您使用 api:// 配置，則直接在 「api://」 後面新增字串值。 例如，api:// string>。< 該字串值可以是 GUID 或任意字串。 如果您新增 GUID 值，它必須符合應用程式識別碼或租使用者識別碼。 應用程式識別碼 URI 值對租使用者而言必須是唯一的。 如果您將 api://< tenantId> 新增為應用程式識別碼 URI，則任何其他應用程式都無法使用該 URI。 建議改為使用 api://< appId> 或 HTTP 配置。
重要
應用程式識別碼 URI 值不得以斜線 「/」 字元結尾。
注意
雖然移除目前租用戶內應用程式註冊的identifierUris是安全的，但移除identifierUris可能會導致用戶端在其他應用程式註冊失敗。
2021 年 8 月
條件式存取只會針對明確要求的範圍觸發
生效日期：2021年8月，從4月開始逐步推出。
受影響的端點：v2.0
通訊協定受到影響：所有使用 動態同意的流程
目前使用動態同意的應用程式會獲得他們同意的所有許可權，即使參數中 scope 的名稱並未要求。 僅 user.read 要求但同意 files.read 的應用程式可以強制傳遞針對 files.read指派的條件式存取需求，例如。
為了減少不必要的條件式存取提示數目，Microsoft Entra ID 會變更為應用程式提供範圍的方式，因此只有明確要求的範圍會觸發條件式存取。 依賴 Microsoft Entra ID 先前行為的應用程式，包括令牌中的所有範圍，不論是否要求，都可能會因為遺漏範圍而中斷。
應用程式現在會收到混合許可權的存取令牌：要求的令牌，以及他們同意的令牌，而不需要條件式存取提示。 令牌的存取範圍會反映在令牌響應的 scope 參數中。
除了觀察到此行為相依性以外的所有應用程式，都會進行這項變更。 如果開發人員不受此變更的豁免，開發人員將會收到外展，因為它們可能會相依於其他條件式存取提示。
範例
應用程式已同意 user.read、 files.readwrite和 tasks.read。 files.readwrite 已套用條件式存取原則，而其他兩個則不會套用。 如果應用程式對 scope=user.read提出令牌要求，且目前登入的使用者尚未通過任何條件式存取原則，則產生的令牌將會是 和 user.readtasks.read 許可權。 tasks.read 包含 ，因為應用程式已同意，因此不需要強制執行條件式存取原則。
如果應用程式接著要求 scope=files.readwrite，則租使用者所需的條件式存取將會觸發，強制應用程式顯示可滿足條件式存取原則的互動式驗證提示。 傳回的令牌將包含其中所有三個範圍。
如果應用程式接著對三個範圍中的任何一個提出最後一個要求（例如， scope=tasks.read），Microsoft Entra ID 就會看到用戶已經完成所需的 files.readwrite條件式存取原則，並再次發出令牌，其中包含所有三個許可權。
2021 年 6 月
裝置程式代碼流程 UX 現在會包含應用程式確認提示
生效日期：2021年6月。
受影響的端點：v2.0 和 v1.0
受影響的通訊協定： 裝置程式代碼流程
為了協助防止網路釣魚攻擊，裝置程式代碼流程現在包含一個提示，可驗證使用者登入他們預期的應用程式。
出現的提示如下所示：
2020 年 5 月
錯誤修正：Microsoft Entra 標識符將不再對狀態參數進行 URL 編碼兩次
生效日期：2021年5月
受影響的端點：v1.0 和 v2.0
通訊協定受到影響：造訪 /authorize 端點的所有流程（隱含流程和授權碼流程）
Microsoft Entra 授權回應中發現並修正了錯誤。 在 /authorize 驗證回合期間， state 來自要求的 參數會包含在回應中，以保留應用程式狀態並協助防止 CSRF 攻擊。 Microsoft Entra ID 在將參數插入回應之前，URL 編碼 state 不正確，而該參數會再次進行編碼。 這會導致應用程式錯誤地拒絕來自 Microsoft Entra 識別碼的回應。
Microsoft Entra ID 將不再對此參數進行雙編碼，讓應用程式能夠正確剖析結果。 所有應用程式都會進行這項變更。
Azure Government 端點正在變更
生效日期：2020 年 5 月 5 日（2020 年 6 月結束）
受影響的端點：全部
受影響的通訊協定：所有流程
2018 年 6 月 1 日，Azure Government 的官方 Microsoft Entra Authority 已從 https://login-us.microsoftonline.com 變更為 https://login.microsoftonline.us。 這項變更也適用於 Microsoft 365 GCC High 和 DoD，Azure Government Microsoft Entra ID 也提供服務。 如果您在美國政府租用戶內擁有應用程式，您必須更新應用程式以在端點上 .us 登入使用者。
2020 年 5 月 5 日，Microsoft Entra ID 將開始強制執行端點變更，封鎖政府使用者使用公用端點登入美國政府租用戶中裝載的應用程式（microsoftonline.com）。 受影響的應用程式將開始看到錯誤 AADSTS900439 - USGClientNotSupportedOnPublicEndpoint。 此錯誤表示應用程式嘗試在公用雲端端點上登入美國政府使用者。 如果您的應用程式位於公用雲端租使用者中，並打算支援美國政府使用者，您必須 更新您的應用程式，以明確支持它們。 這可能需要在美國政府雲端中建立新的應用程式註冊。
強制執行這項變更將會使用漸進式推出，根據美國政府雲端登入應用程式的頻率而定- 不常登入美國政府使用者的應用程式會先看到強制執行，而美國政府用戶經常使用的應用程式將持續套用強制執行。 我們預計在 2020 年 6 月，所有應用程式都會完成強制執行。
如需詳細資訊，請參閱此移轉的 Azure Government 部落格文章。
2020 年 3 月
用戶密碼將限制為 256 個字元。
生效日期：2020 年 3 月 13 日
受影響的端點：全部
受影響的通訊協定：所有使用者流程。
密碼長度超過 256 個字元的使用者，若直接登入 Microsoft Entra ID（不是同盟 IDP，例如 AD FS），他們必須先變更其密碼，才能登入。 管理員 可能會收到協助重設用戶密碼的要求。
登入記錄中的錯誤會類似於 AADSTS 50052：InvalidPasswordExceedsMaxLength。
訊息： The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.
補救措施：
用戶無法登入，因為其密碼超過允許的最大長度。 他們應該連絡其系統管理員來重設密碼。 如果已為其租用戶啟用 SSPR，他們可以遵循 [忘記密碼] 連結來重設其密碼。
2020 年 2 月
空白片段會附加至登入端點的每個 HTTP 重新導向。
生效日期：2020 年 2 月 8 日
受影響的端點：v1.0 和 v2.0
通訊協定受到影響：使用 OAuth 和 OIDC 流程 - 這涵蓋在某些情況下的授權碼流程，以及隱含流程。response_type=query
當驗證回應透過 HTTP 重新導向從 login.microsoftonline.com 傳送至應用程式時，服務會將空白片段附加至回復 URL。 這可藉由確保瀏覽器抹除驗證要求中的任何現有片段，以防止重新導向攻擊的類別。 任何應用程式都不應該相依於此行為。
2019 年 8 月
POST 表單語意將會更嚴格地強制執行 - 空格和引號將被忽略
生效日期：2019 年 9 月 2 日
受影響的端點：v1.0 和 v2.0
受影響的通訊協定：使用隨處 POST （用戶端認證、 授權碼兌換、 ROPC、 OBO 和 重新整理令牌兌換）
從 2019 年 9 月 2 日當周開始，使用 POST 方法的驗證要求將會使用更嚴格的 HTTP 標準進行驗證。 具體而言，空格和雙引號 （“） 將不再從要求窗體值中移除。 這些變更不會中斷任何現有的用戶端，而且可確保每次都可靠地處理傳送至 Microsoft Entra 標識符的要求。 在未來（請參閱上述）中，我們計劃另外拒絕重複的參數，並忽略要求內的 BOM。
範例：
今天， ?e= "f"&g=h 剖析方式 ?e=f&g=h 與 - 因此 e == f相同。 透過這項變更，現在會剖析它， e == "f" 如此一來，這不太可能是有效的自變數，而且要求現在會失敗。
2019 年 7 月
只有用戶端應用程式存在於資源租使用者中時，才會發出單一租使用者應用程式的僅限應用程式令牌
生效日期：2019 年 7 月 26 日
受影響的端點：v1.0 和 v2.0
受影響的通訊協定：客戶端認證（僅限應用程式令牌）
安全性變更於 2019 年 7 月 26 日生效，變更應用程式專用令牌（透過客戶端認證授與）的發行方式。 先前允許應用程式取得令牌來呼叫任何其他應用程式，而不論租使用者或角色中是否同意該應用程式。 此行為已更新，如此一來，針對設定為單一租用戶的資源（有時稱為 Web API），用戶端應用程式必須存在於資源租用戶內。 用戶端與 API 之間的現有同意仍不需要，而且應用程式仍應執行自己的授權檢查， roles 以確保宣告存在，並包含 API 的預期值。
此案例的錯誤訊息目前指出：
The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.
若要解決此問題，請使用 管理員 同意體驗，在您的租使用者中建立用戶端應用程式服務主體，或手動建立它。 這項需求可確保租使用者已授與應用程式在租用戶內運作的許可權。
範例要求
https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... 在此範例中，資源租使用者（授權單位）是 contoso.com，資源應用程式是針對 Contoso 租使用者呼叫 gateway.contoso.com/api 的單一租使用者應用程式，而用戶端應用程式為 00001111-aaaa-2222-bbbb-3333cccc4444。 如果用戶端應用程式在 Contoso.com 內有服務主體，則此要求可以繼續。 不過，如果沒有，要求將會失敗，並出現上述錯誤。
不過，如果 Contoso 閘道應用程式是多租使用者應用程式，則不論用戶端應用程式在 Contoso.com 內有服務主體，要求都會繼續。
重新導向 URI 現在可以包含查詢字串參數
生效日期：2019 年 7 月 22 日
受影響的端點：v1.0 和 v2.0
受影響的通訊協定：所有流程
根據 RFC 6749，Microsoft Entra 應用程式現在可以針對 OAuth 2.0 要求註冊及使用具有靜態查詢參數的重新導向（ https://contoso.com/oauth2?idp=microsoft回復）URI。 動態重新導向 URI 仍然禁止，因為它們代表安全性風險，因此無法用來跨驗證要求保留狀態資訊，因此請使用 state 參數。
靜態查詢參數受限於重新導向 URI 的字串比對，就像重新導向 URI 的任何其他部分一樣 -- 如果沒有註冊符合 URI 譯碼的字串redirect_uri，則會拒絕要求。 如果在應用程式註冊中找到 URI，則會使用整個字串來重新導向使用者，包括靜態查詢參數。
此時（2019 年 7 月底），Azure 入口網站 中的應用程式註冊 UX 仍會封鎖查詢參數。 不過，您可以手動編輯應用程式指令清單，以在應用程式中新增查詢參數並測試此指令清單。
2019 年 3 月
迴圈用戶端將會中斷
生效日期：2019 年 3 月 25 日
受影響的端點：v1.0 和 v2.0
受影響的通訊協定：所有流程
用戶端應用程式有時可能會錯誤，在短時間內發出數百個相同的登入要求。 這些要求可能或可能不會成功，但它們都會導致IDP用戶體驗不佳和工作負載提升、所有用戶延遲增加，並減少IDP的可用性。 這些應用程式是在正常使用範圍之外運作，而且應該更新為正確運作。
發出重複要求的用戶端將會傳送錯誤 invalid_grant ： AADSTS50196: The server terminated an operation because it encountered a loop while processing a request。
大部分的用戶端都不需要變更行為，以避免發生此錯誤。 只有設定錯誤的用戶端（沒有令牌快取或那些已經表現出提示迴圈的用戶端）才會受到此錯誤的影響。 用戶端會根據下列因素，在本機（透過 Cookie）依每個實例追蹤：
使用者提示，如果有的話
要求的範圍或資源
用戶端識別碼
重新導向 URI
回應類型和模式
應用程式在短時間內發出多個要求（15+）將會收到錯誤 invalid_grant ，說明其迴圈。 所要求的令牌具有足夠長時間的存留期（預設至少 10 分鐘，60 分鐘），因此在此期間內重複的要求是不必要的。
所有應用程式都應該 invalid_grant 藉由顯示互動式提示來處理，而不是以無訊息方式要求令牌。 為避免此錯誤，客戶端應確保其正確快取他們收到的令牌。
2018 年 10 月
授權碼無法再重複使用
生效日期：2018 年 11 月 15 日
受影響的端點：v1.0 和 v2.0
受影響的通訊協定： 程序代碼流程
從 2018 年 11 月 15 日開始，Microsoft Entra ID 將會停止接受應用程式先前使用的驗證碼。 這項安全性變更有助於讓 Microsoft Entra 識別符符合 OAuth 規格，並將在 v1 和 v2 端點上強制執行。
如果您的應用程式重複使用授權碼來取得多個資源的令牌，建議您使用程式代碼來取得重新整理令牌，然後使用該重新整理令牌來取得其他資源的其他令牌。 授權碼只能使用一次，但可以在多個資源之間多次使用重新整理令牌。 任何嘗試在 OAuth 程式代碼流程期間重複使用驗證碼的新應用程式，都會收到invalid_grant錯誤。
如需重新整理令牌的詳細資訊，請參閱 重新整理存取令牌。 如果使用 ADAL 或 MSAL 連結函式庫會為您處理此作業 ─ 將的第二個實體 AcquireTokenByAuthorizationCodeAsync 取代為 AcquireTokenSilentAsync。
2018 年 5 月
ID 令牌無法用於 OBO 流程
日期：2018 年 5 月 1 日
受影響的端點：v1.0 和 v2.0
受影響的通訊協定：隱含流程和 代理流程
在 2018 年 5 月 1 日之後，id_tokens無法作為新應用程式的 OBO 流程中的判斷提示。 應該改用存取令牌來保護 API，即使在相同應用程式的用戶端和仲介層之間也一樣。 在 2018 年 5 月 1 日之前註冊的應用程式將繼續運作，並能夠交換id_tokens作為存取令牌：不過，此模式不會被視為最佳做法。
若要解決此問題，您可以執行下列動作：
- 為您的應用程式建立 Web API，並具有一或多個範圍。 這個明確的進入點將允許更精細的控制和安全性。
- 在應用程式的指令清單中，在Azure 入口網站 或應用程式註冊入口網站中，確定允許應用程式透過隱含流程發出存取令牌。 這會透過
oauth2AllowImplicitFlow金鑰來控制。 - 當您的用戶端應用程式透過
response_type=id_token要求id_token時，也會針對上面建立的Web API要求存取令牌 （response_type=token）。 因此，使用 v2.0 端點時，scope參數看起來應該類似api://GUID/SCOPE。 在 v1.0 端點上resource，參數應該是 Web API 的應用程式 URI。 - 將此存取令牌傳遞至中介層，以取代id_token。