You've got OAuth 2.0 working for your mobile app. Users authenticate, get tokens, and call APIs. Everything's smooth. Then, your product team wants users to tap a button in the app and land in a web view, already logged in. No re-auth, no hassle.
The naive approach: pass the access token in a URL parameter. Ship it.
Don't. That token will leak through browser history, referrer headers, and analytics pipelines. You need a secure session transfer pattern, and more importantly, you need to prevent an attacker who steals that token from hijacking the session on a different device.
This is where cryptographic device binding becomes essential.
The Problem: Tokens Are Portable by Design
Access tokens in OAuth 2.0 are bearer credentials. Present a valid token, get access. There's no built-in device verification. If an attacker exfiltrates your token through memory scraping, a compromised SDK, or a man-in-the-middle attack, they can replay it from anywhere.
When you're transferring sessions from app to web, you're creating a new attack surface. The transfer mechanism itself (even if you use Pushed Authorization Requests to keep tokens off the Front-Channel Communication) relies on that access token to establish user context. Without device binding, you're trusting that whoever presents the token is the legitimate device holder.
IP address binding won't save you. Mobile devices change networks constantly. WiFi to cellular, coffee shop to office. Even if you lock the session to the IP that obtained the token, you'll break legitimate use cases. Worse, IP addresses are trivial to spoof through proxies.
You need proof that the device making the session transfer request is the same device that authenticated.
What You Need Before Starting
Infrastructure:
- OAuth 2.0 authorization server with Pushed Authorization Request support
- Mobile app with native authentication (not browser-based)
- MFA service that supports cryptographic device binding (the source implementation uses PingOne MFA with its Automatic Device Authorization capability)
- Identity orchestration engine to handle validation logic
Access:
- Ability to inject custom claims into access tokens
- Control over token introspection and validation flows
- Session management capability in your web application
Prerequisites:
- Existing OAuth 2.0 implementation for your mobile app
- User directory with device association support
- HTTPS everywhere
Step-by-Step Implementation
1. Bind Devices During Registration
When users register in your mobile app, generate a cryptographic device payload. This payload is tied to a private key stored in the device's secure keystore.
Your registration flow should:
- Call your MFA SDK to generate the device payload
- Send the payload to your authorization server during account creation
- Store the associated public key paired with the user profile
The device is now cryptographically bound to the user account. The private key never leaves the device.
2. Authenticate With Device Verification
Modify your mobile authentication flow to prove device ownership on every login:
- Generate a signed payload using your MFA SDK before sending credentials
- Include this payload with the authentication request
- Validate the payload server-side by checking the signature against the stored public key
- Verify the extracted device ID is bound to the authenticating user
If validation succeeds, inject a device_id claim into the issued access token. This claim is critical for step 4.
Store the access token securely in your app's keychain or equivalent protected storage.
3. Initiate Secure Session Transfer
When the user triggers the session transfer (tapping "Manage Profile" or similar):
Create a dedicated OAuth client for session transfers. Configure it with:
- A meaningless scope like
web-session-only - An invalid redirect URI (this client should never complete a full authorization code flow)
- Proof Key for Code Exchange requirement
In your app code:
- Generate a fresh device payload using your MFA SDK
- Retrieve the stored access token
- Build a Pushed Authorization Request containing:
- The access token
- The fresh device payload
- The target web application URL
- A Proof Key for Code Exchange code challenge (discard the verifier)
Send the PAR to your authorization server's PAR endpoint. You'll receive a request_uri in response.
Append this request_uri to your authorization endpoint and open it in a browser or web view.
4. Validate and Create Web Session
Your authorization server receives the front-channel request. Hand it to your orchestration engine for validation:
Introspect the access token:
- Verify it's valid and not expired
- Confirm it was issued to your mobile app client
- Extract the
device_idclaim
Validate the device payload:
- Call your MFA backend to verify the cryptographic signature
- Extract the device ID from the payload
- Confirm this device ID is bound to the user account
Critical check: The device ID from the payload must match the device_id claim in the access token. This proves the device making the transfer request is the same device that authenticated.
Set a short expiration window on the request. The source implementation uses a 10-second exp claim to limit the window for replay attacks.
If all checks pass:
- Extract the
subclaim from the token to identify the user - Set a session cookie in the browser for that user
- Redirect to the target web application URL
5. Complete the Web Application Flow
The web application receives the redirect with an active session cookie. It should now initiate its own standard Authorization Code Flow:
- Use its own client ID and redirect URI
- Request appropriate scopes for web access
- Generate its own Proof Key for Code Exchange challenge
Because the session cookie is present, authentication completes without user interaction. The web app receives a fresh access token scoped for web use.
Validation: How to Verify It Works
Test legitimate flow:
- Authenticate in mobile app
- Trigger session transfer
- Verify web application loads with correct user context
- Confirm no credentials passed in URL parameters
Test device binding enforcement:
- Capture a valid access token from device A
- Attempt to initiate session transfer from device B using the captured token
- Verify the request fails during device validation
- Confirm no session is created
Test token expiration:
- Initiate session transfer
- Wait beyond your configured expiration window (e.g., 10 seconds)
- Attempt to use the
request_uri - Verify the request is rejected as expired
Test network changes:
- Start session transfer on WiFi
- Switch to cellular mid-flow
- Verify transfer completes successfully (proving you're not relying on IP binding)
Maintenance and Ongoing Tasks
Device rotation: Plan for device replacement. When users get new phones, they'll need to re-register their device. Build a flow that lets authenticated users add new devices without full re-registration.
Key rotation: Establish a policy for rotating device keys. Treat device keys like any other cryptographic material.
Monitoring: Track device validation failures. A spike could indicate an attack or a bug in your implementation. Alert on:
- Mismatched device IDs between token and payload
- Expired
request_uriusage attempts - Token introspection failures during session transfer
Token lifetime tuning: Balance security and user experience. Shorter access token lifetimes reduce exposure if tokens are stolen, but may require more frequent re-authentication. Monitor token refresh patterns to find the right threshold.
Audit logging: Log every session transfer attempt with:
- User identifier
- Source device ID
- Target URL
- Validation result
- Timestamp
You'll need this data for security investigations and compliance reporting.
The lift is heavy. You're adding cryptographic operations, server-side validation, and device lifecycle management. But the alternative is accepting that a stolen token equals a stolen session, on any device, anywhere. For high-value applications, that's not acceptable risk.
