Putting access tokens or refresh tokens in plain storage, logs, or crash reports turns a local credential into a reusable session for anyone who can read those artefacts. Access tokens should stay in memory because they are short lived. Refresh tokens should be encrypted at rest, rotated correctly, and cleared when sign out or revocation happens.
Why This Matters for Security Teams
Android token storage mistakes are not just a mobile coding issue. They turn an app session into a portable credential that can be replayed from another device, a rooted handset, a backup file, or a debug log. Once a token is exposed, the attacker does not need the original app code path anymore. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and NHIMG research on mobile secret leakage both point to the same practical risk: storage decisions become authentication decisions.
This is especially dangerous because mobile apps often mix short-lived access tokens with longer-lived refresh tokens, then persist both in places that are easy to extract during device compromise, backup sync, crash collection, or reverse engineering. NHIMG’s IOS app secrets leakage report and the Guide to the Secret Sprawl Challenge show how quickly a single exposed secret can become a repeatable access path across environments. In practice, many security teams discover the problem only after logs, backups, or a compromised handset have already made the token reusable.
How It Works in Practice
The right pattern depends on token type and lifespan. Access tokens should usually remain in memory for the shortest possible time, because they are meant to be transient proof of session state. Refresh tokens can be stored, but only with strong protection, narrow scope, and lifecycle controls. On Android, that usually means encrypted storage, app-level protections, and explicit revocation on sign-out, device loss, or server-side invalidation. If an app uses OAuth, the token handling model should also align with the server’s rotation and revocation behavior, not just the client’s convenience.
Security teams should look for four failure points: tokens written to shared preferences or plaintext files, tokens copied into logs or analytics events, tokens embedded in crash reports, and tokens left valid after logout or account unlinking. The issue is not only where the token lives, but how long it remains valid once stolen. A leaked access token may be usable for a short window, while a leaked refresh token can become a durable session re-entry point. NHIMG’s Guide to the Secret Sprawl Challenge highlights how secrets spread beyond code into telemetry and support systems, which is where mobile tokens often end up unnoticed.
Practitioners should also treat crash collection and support tooling as part of the authentication surface. If a token can appear in a stack trace, support bundle, or remote diagnostics payload, the app has effectively expanded the number of people and systems that can replay it. These controls tend to break down in applications that rely on aggressive logging, third-party analytics, or offline-first sync because those environments multiply token copies faster than developers expect.
Common Variations and Edge Cases
Tighter token protection often increases implementation overhead, requiring organisations to balance user experience, offline availability, and revocation speed against theft resistance. That tradeoff becomes more visible in apps that must survive poor connectivity or device restarts, because access tokens may expire while the app is still trying to function offline.
There is no universal standard for every Android app, but current guidance suggests a few practical distinctions. First, “encrypted at rest” is not enough if the encryption key is stored with equal weakness or if backups still expose the decrypted artifact. Second, biometric or device-bound unlock helps usability, but it does not replace secure token lifecycle design. Third, if a refresh token cannot be rotated or revoked reliably, its value to an attacker may outweigh the convenience it provides. The same logic applies to development and QA builds, where test tokens are frequently weaker and more persistent than production credentials.
This is why breaches involving reused OAuth tokens, such as the Salesloft OAuth token breach, matter to mobile teams even when the exploit path is not Android-specific. They show how a token once exposed can be moved across services and used well outside its original context. For control design, ISO/IEC 27001:2022 Information Security Management supports the broader requirement to manage credentials throughout their lifecycle, not just at creation.
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 AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Token storage and rotation failures are core NHI lifecycle risks. |
| NIST CSF 2.0 | PR.AC-1 | Access credentials must be managed to prevent unauthorized session replay. |
| NIST SP 800-63 | Digital identity guidance supports secure session and token lifecycle handling. | |
| NIST AI RMF | Risk management applies when mobile apps expose reusable authentication material. | |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust requires minimizing trust in stolen or replayed tokens. |
Inventory mobile tokens, enforce rotation, and remove any secret that survives logout or revocation.
