The callback trust model breaks. Any installed app that can claim the same scheme and host may receive the redirect, read the authorization code, and try to complete the token exchange. That failure is especially dangerous when client secrets are hardcoded or otherwise exposed, because the attacker may obtain access tokens without user awareness.
Why the Callback Trust Model Breaks Without App Links
A deep link used as an OAuth callback only works safely when the app can prove it owns that redirect target. Without App Links, Android will route the link by scheme and host matching alone, so any installed app with the same intent filter can intercept the callback. That changes the callback from a trusted handoff into an unauthenticated broadcast.
At that point, the authorization code is no longer bound to the intended app instance. The receiving app can read the redirect, capture the code, and race the real client to the token endpoint. If the authorization server does not enforce PKCE or the client is already exposed through a hardcoded secret, the attacker may be able to complete the exchange and obtain tokens.
For OAuth design, the important distinction is between RFC 6749: The OAuth 2.0 Authorization Framework and the platform trust mechanism that delivers the redirect. OAuth defines the flow, but Android App Links are what make the callback destination verifiable at the app boundary.
What Actually Gets Exposed in the Redirect
The first thing exposed is the authorization code itself, which is usually short-lived but still valuable. If the app uses a plain custom scheme, an attacker does not need to break the authorization server, only to register a competing handler and wait for the redirect. The same weakness becomes worse when the code can be exchanged with weak client authentication or with no proof-of-possession binding.
The second exposure is confusion over which app should receive the result. That confusion matters because a callback is not just another inbound link, it is a security boundary that assumes the right recipient will see the response first. When that assumption fails, the app can no longer rely on the redirect to separate legitimate login completion from interception.
When you review the flow, treat client authentication as a second line of defence rather than the primary fix. RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants shows one way to avoid shared secrets in machine-style authentication, but the core mobile problem is still whether the redirect lands only in the intended app.
How to Recognise a Weak Mobile Authorization Callback Design
A weak design usually has three signs: it uses a custom scheme callback, it does not enforce verified app ownership for the redirect, and it treats the callback URI as if possession of the string alone proves identity. Those are the same conditions that make callback hijacking practical on Android.
Developers also underestimate the effect of a hardcoded client secret. In a mobile app, any embedded secret should be assumed recoverable. Once an attacker can pair redirect interception with a reusable secret, the attack is no longer limited to stealing a one-time code, because they may be able to authenticate as the client repeatedly.
For mobile and API teams, a safer callback design is the one that combines verified app ownership, short-lived codes, PKCE, and no reusable client secret in the app binary. The OAuth server should reject flows that cannot prove the intended app context, and the client should treat the redirect as untrusted until the token exchange succeeds.
Risk and Threat Considerations
Without App Links, the callback path becomes an interception point, not a trust anchor. Any app that can claim the same scheme and host may capture the authorization response, which creates code theft, token theft, and account takeover risk if the rest of the flow is weak.
Failure mechanism: Android resolves the redirect by intent matching instead of verified app ownership, so a malicious app can register the same handler, receive the callback, and race the legitimate client to redeem the authorization code.
Impact: An attacker may obtain access tokens, impersonate the user, or pivot into downstream API access, especially if the client secret is embedded or the authorization server does not strongly bind the code to the intended app.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | OAuth callback hijacking undermines client authentication and token exchange. |
| Recommendation — Enforce PKCE and reject auth flows that do not prove the intended client. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Embedded or reusable client secrets increase token-theft impact after redirect interception. |
| IA-2 — Identification and Authentication (Organizational Users) | The flow depends on strong proof that the receiving app is the intended authenticated party. | |
| Recommendation — Eliminate reusable app secrets and rotate any exposed authenticators immediately. Require strong authentication before issuing tokens to the client context. | ||
Practitioner Guidance
What to verify: Confirm that the callback uses verified App Links, not only a custom scheme, and that the authorization server enforces PKCE for every public client. If the mobile app still contains a reusable secret, treat that as a separate remediation item because it raises the value of any intercepted callback.
What to prioritise: Fix redirect ownership first, then harden token exchange. A secure browser-based login flow can still be broken by an unverified callback, so do not treat login UI correctness as evidence that the redirect path is safe.
Practitioner takeaway: The decisive control is not whether the app can launch the browser flow, but whether only the intended app can receive the authorization response and complete the exchange.
Related resources from NHI Mgmt Group
- What breaks when Android app components are exposed without protection?
- What breaks when Android apps pass untrusted deep-link data into command-line arguments?
- What breaks when deep links are not configured for both app launches and in-app navigation?
- What happens when an Android app uses WebViews without proper validation and safe settings?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
