# Spoofed OAuth app consent and shared clients Consent or tokens attributed to a spoofed or shared OAuth client rather than the real app or host _Area: Web authentication and account takeover. Seen in 2 disclosed reports; one confirmed bounty: $5,000; latest 2026-02-18. Updated 2026-11-02._ ## How it works OAuth binds a grant to a client identity, not to the app the user thinks they approved. Two assumptions break. First, users and downstream systems trust the *displayed* app (name, logo, publisher) and the *client ID* as proof of who is asking; an attacker who registers a lookalike multi-tenant app, or reuses a victim's public client ID with a bogus secret, inherits that trust. Second, the token or cookie is treated as valid for the target it names, without checking that the target matches the host actually being served. When either check is missing, consent or a redirect token minted for one app/host is accepted by another [E1](https://bugbountylibrary.com/r/blog%3Aseblu-de-2021-12-iap-bypass-html.md)[E3](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md). ## Where it shows up - Multi-tenant apps with unverified publisher, missing homepage, reply URL on shared hosting (workers.dev, ClickFunnels), owner domain unrelated to the brand [E3](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md) - Homoglyph or near-duplicate app names/logos; apps consented by only 1-2 users (low tenant prevalence) [E3](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md) - "Shared OAuth client" / key-reuse convenience features where a client ID is accepted with an arbitrary secret across orgs [E1](https://bugbountylibrary.com/r/blog%3Aseblu-de-2021-12-iap-bypass-html.md) - Redirect tokens or session cookies issued without checking `target_uri` against the requested hostname [E1](https://bugbountylibrary.com/r/blog%3Aseblu-de-2021-12-iap-bypass-html.md) - Vendor multi-tenant app credentials that can authenticate to many downstream tenants and write to the directory [E2](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-connectwise-attack-ai.md) ## How to review The invariant: a grant, token or cookie must be bound to the exact client *and* the exact target host it was issued for, and the client must be provably the one the user intended. - For consent: does the app carry a verified publisher and a reply URL on a domain the publisher controls? Is prevalence/age considered before trusting it? - For shared clients: does the server validate the client secret, and reject a client ID used from an unexpected org or host? - For redirect tokens/cookies: is `target_uri` compared to the serving hostname before a session cookie is minted? A mismatch must fail closed. - For vendor apps: is the app's directory-write scope (adding secrets/certs, role assignment) justified, and can the vendor principal grant itself privileged roles? ## How finders spotted it - After failing to bypass IAP directly, pivoted to credential theft; noticed the "Sharing OAuth Clients" feature and hypothesized configuring an attacker app with the victim's client ID; found the secret unvalidated, then saw Error Code 11 fire only after the load balancer forwarded, implying the redirect token reached attacker infrastructure first [E1](https://bugbountylibrary.com/r/blog%3Aseblu-de-2021-12-iap-bypass-html.md) - Compared a homoglyph app's metadata against the legitimate DocuSign app: unverified publisher, missing homepage, free-hosting reply URL, mismatched owner domain, low prevalence; operationalized these into scoring [E3](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md) - Baselines of vendor app user-agent, source range and cadence revealed a script loop and self-granted Global Admin [E2](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-connectwise-attack-ai.md) ## Variants seen - Cross-org reuse of a shared OAuth client ID with a bogus secret, plus hostname-mismatch cookie issuance [E1](https://bugbountylibrary.com/r/blog%3Aseblu-de-2021-12-iap-bypass-html.md) - Compromised vendor multi-tenant app credential replayed across ~1,000 tenants [E2](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-connectwise-attack-ai.md) - Attacker-registered lookalike multi-tenant apps harvesting consent across 20+ orgs [E3](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md) ## Impact and severity Full authentication bypass of IAP-secured apps [E1](https://bugbountylibrary.com/r/blog%3Aseblu-de-2021-12-iap-bypass-html.md); directory-wide takeover via self-granted Global Admin across ~1,000-2,250 tenants [E2](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-connectwise-attack-ai.md); persistent mail/file access surviving password reset and MFA across 20+ orgs [E3](https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md). Impact rises with tenant reach and with chaining minor flaws (shared client + routing + cookie issuance) [E1](https://bugbountylibrary.com/r/blog%3Aseblu-de-2021-12-iap-bypass-html.md)[E2](https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-connectwise-attack-ai.md). ## Evidence - E1: https://bugbountylibrary.com/r/blog%3Aseblu-de-2021-12-iap-bypass-html.md - E2: https://bugbountylibrary.com/r/blog%3Ahuntress-com-blog-connectwise-attack-ai.md - E3: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-detecting-malicious-oauth-applications.md