Topic starter
06/11/2026 6:37 pm
TL;DR: Spoofed OAuth client IDs in Microsoft Entra ID can be used to enumerate accounts, validate passwords, and suppress the sign-in signals defenders depend on, according to Cayosoft’s analysis of Proofpoint research. Detection has to shift from successful sign-ins to reconnaissance patterns and error-code correlation before attackers turn exposed identity data into access.
Editorial analysis by NHI Mgmt Group, based on content published by Cayosoft: “OAuth Client IDs: The New Identity Recon Signal”.
Key questions
Q: What should teams do first when OAuth client ID spoofing is detected?
A: Treat it as a credential and application abuse signal, then contain the affected OAuth app registration, review consent grants, and rotate any secrets or certificates tied to the client.
Q: Why can a public OAuth client ID still help attackers probe identities?
A: A public OAuth client ID can still help attackers because it identifies a known application and lets them test authentication and authorisation flows against it.
Q: How do I reduce the risk from account enumeration in Entra ID?
A: Reduce account enumeration by normalising login and reset responses, limiting error detail, and using rate limiting or smart lockout on repeated sign-in attempts.
Practitioner guidance
- Block legacy credential grant paths Remove or tightly restrict flows that let a client submit usernames and passwords directly to token endpoints, especially where MFA and conditional access are expected to do the real work.
- Correlate unknown client IDs with reconnaissance patterns Alert on repeated failures, multiple targeted users, suspicious AADSTS codes, and unfamiliar source infrastructure when the application identifier does not map cleanly to a tenant application.
- Treat exposed identity data as attack surface Review where usernames, tenant details, and group membership are exposed externally, then assume those values will be used to tune account enumeration and credential testing.
Bottom line: Spoofed OAuth client IDs can turn authentication responses into reconnaissance signals, which is why unknown application identifiers should be treated as suspicious context rather than harmless noise.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
Unknown OAuth client IDs create an identity blind spot, not just a failed-login pattern. The control problem is that many teams key detections to known applications, successful sign-ins, or familiar error paths. When the client ID is spoofed or unmapped, the request can still produce enough response detail to help an attacker validate accounts while looking like ordinary authentication noise. The implication is that telemetry must be judged as reconnaissance, not just as success or failure.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: How do security teams know if OAuth sessions are being abused?
A: Look for repeated token redemptions, unfamiliar geolocation, device changes, and abnormal application access immediately after a successful login. Those signals often reveal misuse that conventional sign-in alerts will miss. Correlating identity provider, application, and proxy logs gives the clearest view of session abuse.
👉 Read our full editorial: Unknown OAuth client IDs expose Entra ID to quiet account probing