How should security teams implement mobile sign-in when the app cannot safely store a client secret?

Why This Matters for Security Teams

Mobile sign-in changes the trust model because the app is a public client: if a client secret is embedded in the APK, it is not a secret for long. Security teams that still expect mobile apps to behave like confidential server-side clients usually end up creating a credential that can be extracted, replayed, or abused at scale. The practical goal is to authenticate the device user without giving the app any long-lived shared credential.

This is why the current guidance aligns with OAuth for public clients, not a shared-secret pattern, and why the OWASP Non-Human Identity Top 10 remains relevant even in mobile contexts: mobile apps often become the distribution point for secrets that should have stayed server-side. NHIMG research shows how quickly exposed credentials become operational risk, with Ultimate Guide to NHIs — Static vs Dynamic Secrets highlighting the scale of long-term secret exposure across modern environments.

In practice, many security teams encounter token theft and unauthorized API use only after a mobile build has already been reverse engineered, rather than through intentional design review.

How It Works in Practice

The safest pattern is to treat the mobile app as a public client and use a browser-based authorization flow with PKCE. The app starts sign-in, the user authenticates in the system browser or a trusted browser tab, and the identity provider returns the authorization response to a registered redirect URI that hands control back to the app. PKCE adds proof that the app that began the flow is the same app that completes it, without requiring a client secret.

After sign-in, keep short-lived access tokens only in memory where possible, and store refresh tokens in encrypted, device-backed storage if the app must retain a session. For higher assurance, pair token handling with device attestation, app integrity checks, and reauthentication for risky actions. The principle is not “never store anything,” but “store only what can be safely revoked, expire quickly, and is useless outside the device.”

Implementation teams should also prefer scoped tokens, narrow audiences, and rotation-friendly session policies. The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is a useful warning sign for mobile governance too: delegated access can spread quickly when tokens are overbroad. For control design, the NIST SP 800-53 Rev. 5 Security and Privacy Controls provides a practical baseline for identity, authentication, and session management expectations.

• Use Authorization Code Flow with PKCE, not a secret-based client flow.
• Register exact redirect URIs and avoid custom schemes that can be hijacked where possible.
• Keep access tokens short-lived and refresh tokens encrypted and device bound.
• Revoke refresh tokens on logout, device loss, or compromise signals.
• Log token issuance, refresh, and revocation events for anomaly detection.

These controls tend to break down when legacy identity providers, embedded webviews, or brittle mobile session layers force teams back into long-lived tokens and unsafe redirect handling.

Common Variations and Edge Cases

Tighter mobile authentication often increases user friction and engineering complexity, so organisations must balance security strength against enrollment failures, account recovery pain, and device diversity. That tradeoff becomes especially visible when supporting older devices, offline use, or regulated environments where browser handoff and secure storage behave inconsistently.

There is no universal standard for every mobile edge case yet. Best practice is evolving around device binding, step-up authentication, and phishing-resistant sign-in, but implementation details differ by platform. On managed devices, stronger local storage and conditional access may be acceptable. On BYOD fleets, the safer assumption is that the app can be copied, inspected, or run in a hostile environment, so secrets must remain ephemeral and revocable. If a product team asks for a client secret in the app, that is usually a sign the architecture is compensating for a server-side design gap, not solving a mobile requirement.

For teams mapping this back to broader identity governance, the Guide to the Secret Sprawl Challenge is a useful reminder that the real failure mode is often accumulation, not one bad login flow. In the mobile case, the correct pattern is to minimize what the app can ever hold, shorten every credential lifetime, and make revocation operationally simple.

Related resources from NHI Mgmt Group

• How should security teams implement Client ID Metadata Documents?
• How should security teams implement PKCE-based sign-in in native mobile apps without exposing secrets in the app bundle?
• How should security teams implement mobile app risk management across the enterprise?
• How should security teams authenticate AI agents in enterprise environments?