Use a backend-for-frontend pattern for web apps that span services, or rely on platform secure storage and short-lived tokens for mobile. That keeps token handling closer to the server or device security boundary and avoids forcing browser storage patterns into environments they do not fit well.
Why This Matters for Security Teams
JWTs become difficult to govern when one identity has to cross browser domains, service boundaries, or mobile app layers. The risk is not the token format itself, but where the token is stored, how long it lives, and which component is trusted to present it. When teams force a single browser-centric pattern onto mobile or multi-domain systems, they usually expand the attack surface instead of simplifying it. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as a control and boundary problem, not just an authentication one.
For web apps that span multiple services, a backend-for-frontend can keep the browser away from broad token exposure. For mobile, platform secure storage and short-lived tokens better match device security boundaries. NHI Management Group has seen this same pattern in its IOS app secrets leakage report, where storage choices became the real issue rather than token format alone. In practice, many security teams encounter token leakage only after a client-side storage decision has already been replicated across products, rather than through intentional platform-specific design.
How It Works in Practice
The practical answer depends on the client type. For browser-based applications that need to reach multiple domains or downstream services, a backend-for-frontend pattern lets the server hold the more sensitive credentials and issue only narrowly scoped browser tokens. That reduces cross-origin token handling and keeps session state closer to a trusted server boundary. For mobile apps, the better pattern is usually short-lived JWTs combined with device-backed secure storage, such as the iOS Keychain or Android Keystore, so the app does not rely on insecure local storage patterns.
The operational goal is to minimize the value of any one stolen token. That means short TTLs, audience restriction, issuer validation, and token scoping to one app or one backend path where possible. It also means treating refresh tokens as high-value secrets and protecting them more tightly than access tokens. Where cross-domain API access is unavoidable, teams should prefer token exchange or a server-mediated session model over placing a reusable bearer token directly in the browser.
- Use a backend-for-frontend when a browser must call multiple internal services.
- Keep access tokens short-lived and scope them to a single audience.
- Store mobile credential only in platform secure storage, never in plain app storage.
- Validate issuer, audience, expiry, and signature on every token path.
- Prefer server-side session mediation when token reuse across domains is unavoidable.
Current guidance suggests this approach aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls by limiting credential exposure and enforcing bounded access decisions. The same principle appears in the NHIMG analysis of Microsoft Azure Key Breach, where secret handling and trust boundaries mattered more than the label on the secret. These controls tend to break down when teams insist on a single token design across web, mobile, and partner integrations because the storage and replay risks differ materially by environment.
Common Variations and Edge Cases
Tighter token scoping often increases integration overhead, requiring organisations to balance developer convenience against replay resistance and incident containment. That tradeoff is most visible in hybrid ecosystems, where a single identity must work across SaaS portals, native mobile apps, and partner APIs. There is no universal standard for this yet, but current best practice is evolving toward per-channel token handling instead of one universal bearer token for every client.
For single-page apps, teams sometimes try to bypass the browser problem with local storage or session storage, but that creates persistent theft risk if XSS lands. For mobile, refresh token rotation and device attestation can help, but they do not replace secure storage or short token lifetimes. In partner or multi-domain setups, federated identity, token exchange, or an intermediary session service may be more appropriate than direct token reuse.
The main edge case is legacy systems that cannot support backend mediation or per-audience tokens. In those environments, the safest approach is usually to reduce token lifetime, limit scope, and isolate domains as much as possible while migration work proceeds. The guidance breaks down most clearly in highly distributed apps that share one login across many independently deployed front ends, because token reuse and revocation become operationally hard to reason about.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | JWT handling across clients is an NHI credential boundary issue. |
| NIST CSF 2.0 | PR.AC-3 | Cross-domain token use depends on access enforcement at the right boundary. |
| NIST SP 800-63 | Session and token lifecycle choices affect digital identity assurance. | |
| NIST Zero Trust (SP 800-207) | Zero trust supports verifying each token use rather than trusting the channel. | |
| NIST AI RMF | AI systems using JWTs need governance around identity and boundary risk. |
Document token handling risks and assign ownership for client-specific controls.
