Native-to-Web SSO
Session transfer token · Single-use · 60s expiry · IP-bound
Architecture & Token Flow
1. Native app login
2. Get transfer token
3. Authorize web app
4. Both sessions
Native App
Sign in to the simulated native app. This uses a server-side Auth0 client configured with session_transfer.can_create_session_transfer_token: true. It requests offline_access so it holds a refresh token — that RT is what gets exchanged for the session transfer token in step 2.
Security Implications
Strengths
- Session Transfer Tokens let a trusted native app hand off to a web view without re-prompting for credentials.
- Short-lived, single-use by design — narrower attack window than a long-lived credential.
Risks & Considerations
- An STT minted for one target audience being accepted by a different one is a real class of bug — this exact issue was hit and fixed in this project (see the "Session Transfer Token Audience Gotcha" post).
- A leaked STT during its short validity window is a full session handoff, not a degraded one — without device binding (see the Cross-Domain SSO demo, which uses the same STT mechanism), a leaked token can be redeemed from any network, not just the device that minted it.
Hardening Checklist
- Always set the correct target audience explicitly per exchange — never assume a default.
- Keep STT lifetime as short as the UX will tolerate.
- Allowlist the redirect/target URLs an STT can be redeemed against; don't accept an open target parameter.
- Enable device binding (enforce_device_binding) so a leaked STT is tied to the native client's own context, not just its short expiry.