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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Cayosoft's blog post: Spoofed OAuth client IDs can help attackers enumerate Entra ID accounts, test credentials, and blur the telemetry defenders rely on.
Why it matters: Identity teams need to treat exposed usernames and tenant details as attack inputs, because reconnaissance against authentication workflows often precedes phishing, password spraying, and targeted access attempts.
Context
OAuth client IDs are public identifiers, not secrets, and that distinction matters because identity providers often surface them in authentication telemetry. When attackers can spoof the identifier that ties a request to a known application, they can probe response behavior without first breaking into an account.
The governance gap is not just weak authentication. It is a detection model that assumes attacks will look like successful sign-ins or obvious password sprays. Once identity data is exposed, the more likely next step is OAuth and OpenID Connect flows probing that blends into routine failure noise unless teams correlate the surrounding signals.
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. Investigate the spoofed client ID against sign-in logs and AADSTS error patterns, because repeated token or authorisation failures can reveal where the impersonation is being attempted and what scope the attacker is trying to reach.
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. Combined with error responses, it can expose whether a tenant exists, whether a user name is valid, or whether the app is correctly registered, which helps refine phishing, token abuse or replay attempts.
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. Where possible, hide exposed usernames in directory listings and audit logs, and restrict what unauthenticated users can query through self-service or lookup features so valid accounts are harder to confirm.
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.
Technical breakdown
How spoofed OAuth client IDs change authentication telemetry
In OAuth, the client ID identifies the application making the request. It is public by design, so the security value comes from matching that identifier to a registered application object, expected behaviour, and known owner. When an attacker submits a fabricated or unknown client ID, the identity provider can still emit response codes that reveal whether the username exists, whether the password was wrong, or whether the pair may be valid. That turns protocol feedback into reconnaissance. The problem is not merely that the request fails. The problem is that the failure path can disclose enough structure for an attacker to learn which accounts are worth pursuing. Read OAuth 2.0 and OpenID Connect Guide for Identity Teams.
Practical implication: Treat unknown client ID activity as identity reconnaissance, not routine application noise, and correlate it with user targeting and error-code patterns.
Why the resource owner password credentials flow amplifies this risk
The resource owner password credentials flow sends a username and password directly to the token endpoint. Because the flow exposes credential-verification behaviour in a simple request-response pattern, it is attractive for automated testing and credential validation. Modern identity programmes try to reduce or eliminate this pattern because it bypasses stronger interaction models such as phishing-resistant authentication and conditional control placement. In practice, the flow can become a low-friction probe for attackers who already have exposed identity data and want to test which accounts respond as expected without generating a loud compromise event.
Practical implication: Block or tightly restrict legacy grant patterns that let attackers turn identity data into validation signals.
How exposed identity data becomes an attack input
Email addresses, usernames, tenant details, job titles, and group membership are not passive records once they leave trusted boundaries. They give attackers the raw material to tune enumeration, select likely targets, and shape authentication probes so they look less anomalous. In Entra ID environments, even partial identity knowledge can help an attacker distinguish valid users from guesses and infer which accounts may support future phishing or password spraying. That is why identity exposure should be treated as an access-risk issue, not just a privacy or data-handling issue. See the Workforce Identity Security Guide.
Practical implication: Reduce the discoverability of tenant identity data and assume any exposed identifier will be used for probing.
Breaches seen in the wild
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Exposed identity data has become attacker-ready input. Usernames, email addresses, tenant names, and group membership let an adversary shape authentication tests before any real compromise occurs. That changes the risk model for data exposure because the security impact is no longer limited to privacy or phishing follow-on. The implication is that identity data handling has to be treated as part of the access-control boundary, not as a separate hygiene issue.
ROPC is a governance shortcut that weakens the meaning of identity signals. A flow that lets a client submit credentials directly to the token endpoint gives attackers an efficient validation channel when they already know who exists in the tenant. That does not create the identity problem, but it magnifies it by preserving a probeable path in the authentication stack. The implication is that organisations should regard legacy grant use as a detection and assurance liability, not only an authentication preference.
Credential validation is the more important stage than initial access in these campaigns. Proofpoint’s research, as cited by Cayosoft, shows the technique is being used to learn which accounts and credentials are worth pursuing before defenders see obvious compromise. That makes early-stage identity testing part of the attack chain, not a prelude to it. The implication is that identity programmes need to operationalise reconnaissance as a first-class threat event.
Application context is part of identity trust. Known OAuth client IDs carry owner, purpose, and expected behaviour, which helps defenders distinguish a legitimate application from a probe. When that context is missing, the telemetry loses one of the few anchors analysts use to triage authentication events at scale. The implication is that authentication monitoring must preserve application metadata as an enforcement signal, not just as a convenience field.
From our research library:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
What this signals
Application context is now part of the trust boundary. In identity systems, the ability to match a client ID to a known owner and expected sign-in pattern is not metadata fluff. It is what turns an authentication event into an interpretable security signal. When that context disappears, detection quality drops even if the underlying protocol stays the same.
Security teams should assume that exposed identity data will be operationalised quickly. A username is often enough to move an attacker from broad guessing to focused validation, which means detection strategy has to shift left from compromise to reconnaissance.
The practical test is whether your telemetry can distinguish a genuine application from a spoofed one before the attacker reaches a successful sign-in. If it cannot, the identity programme has left a blind spot in the place where the attack starts.
For practitioners
- 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.
- Preserve application context in authentication monitoring Make application owner, expected sign-in behaviour, and historical sign-in patterns available in detection workflows so unknown or spoofed client IDs do not collapse into generic failure noise.
Key takeaways
- 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.
- Exposed usernames, tenant details, and group membership materially increase the value of identity probing because they help attackers validate who exists and which credentials respond.
- Detection needs to move beyond successful sign-ins and watch for unknown client IDs, repeated failures, and error patterns that indicate account enumeration or credential testing.
Related NHI Mgmt Group resources: OAuth 2.0 and OpenID Connect Guide for Identity Teams · Workforce Identity Security Guide · Identity Provider and SSO Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Spoofed OAuth client IDs exploit weakly governed authentication flows and response leakage in Entra ID. |
| NHI-10 — Human Use of NHI | Exposed identity data and client identifiers are being used by humans to drive machine authentication probes. | |
| Recommendation — Harden authentication monitoring around NHI-04 by flagging spoofed client IDs and abnormal validation responses. Apply NHI-10 thinking to distinguish legitimate application use from human-driven abuse of identity signals. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | Detection of unknown client IDs depends on monitoring authentication events for suspicious patterns. |
| Recommendation — Monitor authentication telemetry for repeated failures, unmapped applications, and error-code patterns that indicate reconnaissance. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential validation risk rises when legacy flows allow direct username and password submission. |
| Recommendation — Apply IA-5 to restrict legacy credential-grant paths and reduce validation channels. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The campaign pattern centers on validating usernames and passwords before overt compromise. |
| Recommendation — Map unknown client ID activity to TA0006 and hunt for credential testing across multiple accounts. | ||
Key terms
- OAuth Client ID: An OAuth Client ID is the public identifier an application uses when it asks an authorization server for access. It tells the server which client is making the request, but it is not a secret. In practice, it is paired with a client secret or other proof method to support secure authorization flows.
- Resource Owner Password Credentials Flow: Resource Owner Password Credentials Flow is an OAuth 2.0 grant where an application collects a user’s username and password directly and exchanges them for an access token. It bypasses the normal browser-based authorisation step, so the client sees the user secret and the trust boundary is weaker than in redirect-based flows.
- Account Enumeration: Account enumeration is the process of discovering which user or system accounts exist in a target environment. Attackers use login pages, password reset flows, API responses, or directory queries to confirm valid identities, then focus phishing, password attacks, or privilege abuse on those accounts. It weakens IAM and NHI security.
- AADSTS Error Codes: AADSTS error codes are the numeric and alphanumeric codes returned by Microsoft Entra authentication and token services when a sign-in, consent, or token request fails. They map specific identity and OAuth failure conditions, such as invalid credentials, tenant mismatch, consent issues, or conditional access blocks, and are used for troubleshooting and attack analysis.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org