驗證有什麼新功能？
Microsoft 會定期新增和修改 Microsoft 身分識別平台的功能，以改善其安全性、可用性和標準合規性。
除非另有註明，否則此處所述的變更僅適用於在變更指定有效日期之後註冊的應用程式。
請定期查看此文章以了解：
- 已知問題與修正
- 通訊協定變更
- 過時的功能
提示
若要取得此頁面的更新通知，請將此 URL 新增至 RSS 摘要讀取器：https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us
2024 年 8 月
同盟身分識別認證現在使用區分大小寫的比對
生效日期： 2024年9月
受影響的通訊協定： 工作負載身分識別同盟
變更
先前，當比對外部IdP傳送至 Microsoft Entra 識別碼之令牌中所含的對應issuer、 subject和 audience audience 值時subjectissuer，會使用不區分大小寫的比對。 為了為客戶提供更精細的控制，我們會切換為強制執行區分大小寫的比對。
無效的範例：
- 令牌主體：
repo:contoso/contoso-org:ref:refs/heads/main - FIC 主旨：
repo:Contoso/Contoso-Org:ref:refs/heads/main
這兩個主旨值不區分大小寫相符，因此驗證失敗。 相同的機制會套用至 issuer 和 audience 驗證。
這項變更一開始會套用至在 之後 August 14th, 2024建立的應用程式或受控識別。 非使用中應用程式或受控識別，由上述應用程式或受控識別在 期間之間的August 1st, 2024August 31st, 2024零工作負載身分識別同盟要求決定，必須使用區分大小寫的比對開始September 27th, 2024。 針對作用中應用程式，不區分大小寫的比對會在稍後的日期進行通訊。
為了更清楚地顯示因不區分大小寫而失敗，我們正在針對 重新整理錯誤訊息 AADSTS700213。 它現在會陳述;
`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.`
佔位元 '{subject}' 提供從外部 IdP 傳送 Microsoft 至 entra IDa 識別符之令牌中包含的主體宣告值。 此錯誤範本也用於不區分大小寫的失敗和issueraudience驗證。 如果您遇到此錯誤，您應該會找到對應至 issuersubject、 或 audience 列在錯誤中的同盟識別認證，並確認對應值與區分大小寫的檢視方塊相等。 如果不相符，您必須將 FIC 中的目前 issuer、 subject或 audience 值取代為 issuer錯誤訊息中包含的、 subject或 audience 值。
注意
對於使用 GitHub Actions 並執行此錯誤的 Azure App 服務 客戶，尋址的選項是移至 GitHub 存放庫中的 /.github/workflows 工作流程檔案，並將 environment name 屬性從 "Production" 更新為 "production"。 本指南僅適用於 Azure App 服務 案例。 如果您在不同的案例中遇到此錯誤，請參閱上述指引。
2024 年 6 月
必須在目錄中註冊應用程式
生效日期：2024 年 6 月
受影響的端點：v2.0 和 v1.0
受影響的通訊協定：所有流程
變更
先前，使用 Microsoft Entra 應用程式註冊體驗註冊應用程式時，如果使用者使用其個人Microsoft帳戶 （MSA） 登入，他們可以選擇只將應用程式與其個人帳戶產生關聯。 這表示應用程式不會與任何目錄相關聯或包含在任何目錄中（也稱為「租使用者」或「組織」）。 不過，從 2024 年 6 月開始，必須在目錄中註冊所有應用程式。 這可能是現有的目錄，或個人Microsoft帳戶使用者建立的新目錄，用來存放其Microsoft Entra 應用程式和其他Microsoft資源。 使用者可以加入 Microsoft 365 開發人員計劃或註冊 Azure，輕鬆地建立新的目錄以供此用途使用。
在目錄中註冊應用程式，而不是只將其與個人帳戶產生關聯，具有各種優點。 包括：
- 在目錄中註冊的應用程式有更多的功能可供他們使用，例如能夠將多個擁有者新增至應用程式，以及發行者驗證應用程式的能力。
- 應用程式所在的位置與其他開發人員所使用的Microsoft資源相同，例如 Azure 資源。
- 應用程式會收到改善的復原優點。
這不會影響任何現有的應用程式，包括只與個人帳戶相關聯的現有應用程式。 只會影響註冊新應用程式的能力。
2023 年 10 月
已更新 RemoteConnect UX 提示
生效日期：2023 年 10 月
受影響的端點：v2.0 和 v1.0
受影響的通訊協定：RemoteConnect
RemoteConnect 是一種跨裝置流程，用於 Microsoft Authentication Broker 以及涉及主要重新整理權杖的 Microsoft Intune 相關案例。 為了協助防止網路釣魚攻擊，RemoteConnect 流程會接收更新的 UX 語言，以呼叫遠端裝置（起始流程的裝置）能夠在順利完成流程時存取貴組織使用的任何應用程式。
出現的提示看起來會像這樣：
2023 年 6 月
遺漏具有未驗證網域擁有者的電子郵件宣告
生效日期：2023 年 6 月
受影響的端點：v2.0 和 v1.0
變更
對於「多租用戶應用程式」，在權杖承載中要求選擇性 email 宣告時，預設會省略未驗證網域擁有者的電子郵件。
如果出現下列狀況，則會將電子郵件視為通過網域擁有者驗證：
- 網域屬於使用者帳戶所在的租用戶，而租用戶系統管理員已完成網域的驗證。
- 電子郵件來自 Microsoft帳戶 (MSA)。
- 電子郵件來自 Google 帳戶。
- 電子郵件已用於使用一次性密碼 (OTP) 流程進行驗證。
此外，請注意，Facebook 和 SAML/WS-Fed 帳戶沒有已驗證的網域。
2023 年 5 月
Power BI 管理員角色將會重新命名為網狀架構管理員。
生效日期：2023 年 6 月
受影響的端點：
- 列出 roleDefinitions：Microsoft Graph v1.0
- 列出 directoryRoles：Microsoft Graph v1.0
變更
Power BI 系統管理員角色會重新命名為網狀架構系統管理員。
在 2023 年 5 月 23 日，Microsoft 推出 Microsoft Fabric，其提供 Data Factory 所支援的資料整合體驗、Synapse 所支援的資料工程、資料倉儲、資料科學，以及使用 Power BI 的即時分析體驗和商業智慧 (BI)，而這些全部都裝載於以資料湖為中心的 SaaS 解決方案。 這些體驗的租用戶和容量管理會集中在網狀架構管理員入口網站中 (先前稱為 Power BI 管理員入口網站)。
從 2023 年 6 月開始，Power BI 系統管理員角色會重新命名為 Fabric 系統管理員，以配合此角色變更的範圍和責任。 所有應用程式 (包括 Microsoft Entra ID、Microsoft Graph API、Microsoft 365 和 GDAP) 都會在數週內開始反映新的角色名稱。
提醒您，您的應用程式碼和指令碼不應該根據角色名稱或顯示名稱來做出決策。
2021 年 12 月
AD FS 使用者會看到更多登入提示，以確保正確的使用者已登入。
生效日期：2021 年 12 月
受影響的端點：整合式 Windows 驗證
受影響的通訊協定：整合式 Windows 驗證
變更
今天，當將使用者傳送到 AD FS 進行驗證時，會以無訊息方式將其登入到任何已經具有 AD FS 工作階段的帳戶。 即使使用者想要登入不同的使用者帳戶，也會發生無訊息登入。 為了減少發生此錯誤登入的頻率，從 12 月開始，如果 Windows 中的 Web 帳戶管理員在登入期間將 login_hint 提供給 Microsoft Entra ID，則 Microsoft Entra ID 將會向 AD FS 傳送 prompt=login 參數，指出需要特定使用者才能登入。
符合上述需求時 (使用 WAM 將使用者傳送至 Microsoft Entra ID 進行登入，並包括 login_hint，而且使用者網域的 AD FS 執行個體支援 prompt=login)，使用者不會以無訊息方式登入，而是改為要求提供使用者名稱才能繼續登入 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 錯誤回應。
錯誤案例已更新，因此在非互動式驗證期間 (其中 prompt=none 用於隱藏 UX)，將指示應用程式使用 interaction_required 錯誤回應執行互動式驗證。 在後續的互動式驗證中，Microsoft Entra ID 現在將保留使用者，並直接顯示錯誤訊息，以防止迴圈發生。
提醒您，您的應用程式程式碼不應該根據類似 AADSTS50105 的錯誤碼字串做決策。 相反地，請遵循我們的錯誤處理指導，並使用在標準 error 欄位中找到的 interaction_required 和 login_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 或將新的識別碼 URI 新增至 identifierUri 集合時進行驗證。 新的限制僅適用於 2021 年 10 月 15 日之後新增至應用程式 identifierUris 集合的 URI。 在該限制於 2021 年 10 月 15 日 生效時，早已位於應用程式 identifierUris 集合中的 AppId URI 將會繼續運作，即使您將新的 URI 新增至該集合中。
如果要求未通過驗證檢查，則用於建立/更新的應用程式 API 將會傳回 400 badrequest 給用戶端，指出 HostNameNotOnVerifiedDomain。
支援下列 API 和以 HTTP 配置為基礎的應用程式識別碼 URI 格式。 將預留位置值取代為下表清單中所述的項目。
| 支援的應用程式識別碼 URI 格式 |
範例應用程式識別碼 URI |
|---|---|
| api://<應用程式識別碼> | api://00001111-aaaa-2222-bbbb-3333cccc4444 |
| api://<租用戶識別碼>/<應用程式識別碼> | api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444 |
| api://<租用戶識別碼>/<字串> | api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api |
| api://<字串>/<應用程式識別碼> | api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444 |
| https://<tenantInitialDomain>.onmicrosoft.com/<字串> | https://contoso.onmicrosoft.com/productsapi |
| https://<已驗證的自訂網域>/<字串> | https://contoso.com/productsapi |
| https://<字串>.<已驗證的自訂網域> | https://product.contoso.com |
| https://<字串>.<已驗證的自訂網域>/<字串> | https://product.contoso.com/productsapi |
- <appId>：應用程式物件的應用程式識別碼 (appId) 屬性。
- <string>：主機或 API 路徑線段的字串值。
- <tenantId>：Azure 所產生的 GUID，用來代表 Azure 內的租用戶。
- <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com，其中 <tenantInitialDomain> 是租用戶建立者在建立租用戶時指定的初始網域名稱。
- <verifiedCustomDomain>：為 Microsoft Entra 租用戶設定的已驗證自訂網域。
注意
如果您使用 api:// 配置，請直接在 "api://" 之後新增字串值。 例如 api://<字串>。 該字串值可以是 GUID 或任意字串。 如果您新增 GUID 值，其必須符合應用程式識別碼或租用戶識別碼。 應用程式識別碼 URI 值對租用戶來說必須是唯一的。 如果您新增 api://<租用戶識別碼> 作為應用程式識別碼 URI，其他人將無法在任何其他應用程式中使用該 URI。 建議使用 api://<應用程式識別碼>，或改為使用 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.read 和 tasks.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 ID 將不再對狀態參數進行兩次 URL 編碼
生效日期：2021 年 5 月
受影響的端點：v1.0 和 v2.0
受影響的通訊協定：造訪 /authorize 端點的所有流程 (隱含流程和授權碼流程)
在 Microsoft Entra 授權回應中，發現並修正錯誤。 在驗證的 /authorize 階段，回應中包含來自要求的 state 參數，以保留應用程式狀態並協助防止 CSRF 攻擊。 Microsoft Entra ID 在將 state 參數插入回應之前對其進行錯誤的 URL 編碼，其在回應中再次對其進行編碼。 這會導致應用程式不正確地拒絕來自 Microsoft Entra ID 的回應。
Microsoft Entra ID 將不再對該參數進行雙重編碼，從而讓應用程式能夠正確地剖析結果。 將會針對所有應用程式進行此變更。
Azure Government 端點正在變更
生效日期：2020 年 5 月 5 日 (於 2020 年 6 月完成)
受影響的端點：所有
受影響的通訊協定：所有流程
在 2018 年 6 月 1 日，Azure Government 的官方 Microsoft Entra 授權單位已從 https://login-us.microsoftonline.com 變更為 https://login.microsoftonline.us。 這種變更也適用於 Azure Government Microsoft Entra ID 也提供服務的 Microsoft 365 GCC High 和 DoD。 如果您在美國政府租用戶中擁有應用程式，則必須更新應用程式，以便使用者在 .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
受影響的通訊協定：使用 response_type=query 的 OAuth 和 OIDC - 這涵蓋某些案例中的授權碼流程以及隱含流程。
當驗證回應透過 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 ID 的要求。 在未來 (請參閱上述)，我們計劃另外拒絕重複的參數，並忽略要求內的 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 應用程式現在可以註冊並使用帶有靜態查詢參數 (如 https://contoso.com/oauth2?idp=microsoft) 的重新導向 (回覆) URI 來處理 OAuth 2.0 要求。 仍然禁止動態重新導向 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) 追蹤：
使用者提示 (如果有的話)
要求的範圍或資源
Client ID
重新導向 URI
回應類型和模式
在短時間 (5分鐘) 內發出多個要求 (15+) 的應用程式將接收 invalid_grant 錯誤，說明其正在迴圈。 要求的權杖有足夠長的存留期 (至少 10 分鐘，預設情況下為 60 分鐘)，因此不需要在這段時間內重複要求。
所有應用程式都應該透過顯示互動式提示來處理 invalid_grant，而不是以無訊息方式要求權杖。 若要避免此錯誤，用戶端應該確保其能夠正確地快取其所接收的權杖。
2018 年 10 月
授權碼再也無法重複使用
生效日期：2018 年 11 月 15 日
受影響的端點：v1.0 和 v2.0
受影響的通訊協定：碼流程
從 2018 年 11 月 15 日開始，Microsoft Entra ID 將不再接受將先前使用的驗證碼用於應用程式。 這項安全性變更有助於讓 Microsoft Entra ID 與 OAuth 規格一致，而且將會對 v1 和 v2 端點強制執行。
如果您的應用程式重複使用授權碼取得多個資源的權杖，建議您先使用授權碼取得重新整理權杖，再使用該重新整理權杖取得其他資源的額外權杖。 授權碼只能使用一次，但重新整理權杖可跨多個資源多次使用。 在 OAuth 程式碼流程期間嘗試重複使用驗證碼的任何新應用程式，會收到 invalid_grant 錯誤。
如需關於重新整理權杖的詳細資訊，請參閱重新整理存取權杖。 如果使用 ADAL 或 MSAL 這會由程式庫為您處理 - 以 AcquireTokenSilentAsync 取代 AcquireTokenByAuthorizationCodeAsync 第二執行個體。
2018 年 5 月
識別碼權杖無法用於 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。