Mobile T1635 Steal Application Access Token: Stopping OAuth Code and Token Interception in Mobile Apps

When a mobile app signs a user in through OAuth, the authorisation code comes back to the app through a URI the operating system routes, and a malicious app that claims the same URI can catch it. MITRE ATT&CK for Mobile tracks this as T1635 Steal Application Access Token, a Credential Access technique listed for Android and iOS, with one sub-technique, T1635.001 URI Hijacking. Unlike most mobile techniques, the fix sits largely with app developers and identity teams: verified links, PKCE and token design. This guide covers how the interception works at a defensive level, the Android and iOS controls that bind links to the right app, the OAuth requirements from the IETF, and how to detect and respond. For the matrix as a whole, see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Custom URI schemes are unverified. Any installed app can register the same myapp:// scheme, which is the opening T1635.001 uses.
• Verified links close the gap. Android App Links and iOS Universal Links bind an HTTPS domain to a specific signed app; ATT&CK names both as the developer mitigation.
• PKCE makes a stolen code useless. RFC 7636 and RFC 9700 require public clients to use PKCE with S256, so an intercepted code cannot be redeemed without the verifier.
• Tokens are the real prize. Access and refresh tokens act for the user without a password or MFA prompt, so keep them short-lived and rotate or sender-constrain refresh tokens.
• Detection lives in identity logs. Device telemetry rarely shows the interception; token use from an unexpected client, device or location usually does.

What T1635 covers

ATT&CK describes Steal Application Access Token as stealing user application access tokens to gain credentials for remote systems and resources, through social engineering or URI hijacking, typically with user action such as an "Open With" dialogue. It notes that tokens are used to make authorised API requests on behalf of a user, commonly for cloud and SaaS resources, and that an OAuth access token lets an application act on user data without the user's credentials.

T1635.001 URI Hijacking covers registering a URI that a genuine app already uses, so redirections meant for the genuine app are intercepted. ATT&CK says intercepted data may include OAuth authorisation codes or tokens, and that the same trick can be used to phish the genuine app's users. T1635.001 replaced the older IDs T1415 URL Scheme Hijacking and T1416 URI Hijacking, both now revoked. The Enterprise equivalent is T1528, covered in MITRE ATT&CK T1528 Steal Application Access Token Guide. ATT&CK v20 lists no procedure examples (software, groups or campaigns) for T1635 or T1635.001.

Why the interception works

RFC 7636 describes the attack it was written to stop: a native app receives its authorisation code through a custom URI scheme, a malicious app registers the same scheme, and with the code plus the public client_id it obtains an access token. TLS does not help, because the redirect happens inside the operating system, not over the network. RFC 8252 (BCP 212, OAuth 2.0 for Native Apps) adds that several apps can register the same private-use scheme and recommends claimed HTTPS redirect URIs where possible, because the operating system verifies the app's identity.

RFC 8252 also requires native apps to send authorisation requests through an external user agent, usually the system browser, not an embedded webview, because an embedded webview lets the host app capture credentials and cookies.

Platform controls: Android and iOS

The deeper design of deep links is in the Mobile Deep Link and App Link Security Guide.

OAuth requirements that defeat the technique

• PKCE with S256: RFC 7636 says clients that can support S256 must use it and must not fall back to plain. RFC 9700 (BCP 240) requires public clients to use PKCE and requires servers to enforce the verifier when a challenge was sent and to reject a verifier sent without one.
• Refresh token protection: RFC 9700 states that refresh tokens for public clients must be sender-constrained or use refresh token rotation. Sender-constraining uses mutual TLS (RFC 8705) or DPoP (RFC 9449).
• Exact redirect URI matching at the authorisation server, with reverse-domain private-use schemes only, as RFC 8252 section 8.4 advises for registration.
• Short access token lifetimes and scopes limited to what the app needs. See API Keys vs OAuth Tokens Guide.

Implementation sequence

1. Inventory: list every mobile app (yours and third-party apps your IdP trusts) and its redirect URIs; flag custom schemes.
2. Enforce PKCE: turn on mandatory PKCE with S256 for all public mobile clients at the IdP; test in a staging tenant first, since clients without PKCE will fail.
3. Move to verified links: publish assetlinks.json and apple-app-site-association, ship app updates using HTTPS redirect URIs, and keep the old scheme registered at the IdP until adoption passes your threshold.
4. Remove old schemes: delete custom-scheme redirect URIs from the client registration once usage drops; rollback is re-adding them.
5. Harden tokens: enable refresh token rotation or DPoP, shorten access token lifetimes and add reuse detection.
6. Gate with attestation: require Play Integrity or App Attest signals at token issuance for high-value apps; see Mobile App Attestation.

Detection and response

ATT&CK's detection strategy for T1635.001 on Android looks during app vetting for two or more apps with identical URI scheme intent filters, or a custom-scheme query that returns more than one handler. On iOS it relies on vetting entitlements and network flow metadata. For a SOC, identity logs carry most of the signal:

• Vetting: flag apps that register URI schemes belonging to your apps or your IdP clients.
• IdP logs: authorisation code redemption failures with invalid_grant on PKCE mismatch, refresh token reuse events, and tokens used from a device, ASN or location that does not match the session.
• Device: MDM or MTD inventory showing an unapproved app that claims a corporate scheme.

Response: revoke the user's refresh tokens and sessions, remove the offending app, and review what the token's scopes could reach. See How to detect use of a stolen OAuth refresh token and the Global Token Revocation Guide.

Metrics

• Share of mobile OAuth clients with PKCE S256 enforced (target: 100 percent).
• Share of mobile redirect URIs that are verified HTTPS links.
• Share of mobile refresh tokens that are rotated or sender-constrained.
• Count of refresh token reuse or PKCE failure events per week, and time to revoke.

Where identity fits

An OAuth client registration is a non-human identity: it has redirect URIs, scopes and token policies that decide who receives tokens. Mobile clients are public clients with no secret, so the redirect URI and PKCE are their only proof. Own each client registration, review its redirect URIs and scopes, and never embed a client secret in a mobile app. See the Mobile Access Credentials guide.

Common failure patterns

• PKCE optional at the IdP: clients that skip it are accepted, so the protection exists only on paper.
• Short, generic schemes: names like myapp:// invite collisions; RFC 8252 asks for reverse-domain names.
• Embedded webviews for login: the host app sees the credentials and SSO breaks.
• Long-lived, unbound refresh tokens: one stolen token gives months of access.
• Verification files not maintained: a broken assetlinks.json or AASA file after a signing key or domain change silently drops apps back to unverified behaviour.

Framework mapping

Practitioner checklist

• Enforce PKCE with S256 for every public mobile client at the authorisation server.
• Use App Links and Universal Links for OAuth redirects; keep custom schemes reverse-domain only.
• Use the system browser or platform auth session for login, never an embedded webview.
• Rotate or sender-constrain mobile refresh tokens and shorten access token lifetimes.
• Monitor assetlinks.json and AASA files as production assets.
• Alert on refresh token reuse and PKCE failures, and rehearse revocation.
• Vet apps for schemes that collide with your own.

Standards and references

• MITRE ATT&CK: T1635 Steal Application Access Token (Mobile)
• MITRE ATT&CK: T1635.001 URI Hijacking
• IETF: RFC 7636 Proof Key for Code Exchange by OAuth Public Clients
• IETF: RFC 8252 OAuth 2.0 for Native Apps
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• Android Developers: Handling Android App Links
• Android Developers: Play Integrity API integrity verdicts
• OWASP: Mobile Application Security Verification Standard

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Deep Link and App Link Security Guide · Consent Phishing and Illicit OAuth Grants Guide · Mobile App Security Guide