Topic guide · 3 min read
Mobile app security and OAuth
Short answer
Secure mobile access combines a correct OAuth implementation in the app (authorization code flow with PKCE in the system browser, tokens in the keychain or keystore), protections for the API (short-lived, possibly sender-constrained tokens, app attestation), and device-level controls (MDM or work profiles for BYOD) evaluated by the identity provider at sign-in.
Key takeaways
- Native apps are public clients: PKCE, no embedded secrets, system browser for sign-in.
- App attestation services help an API tell the genuine app from scripts and modified copies.
- For personal devices, protect work data in managed apps or work profiles instead of managing the whole phone.
Mobile security has two halves that often sit in different teams. App developers worry about how the app signs users in and talks to APIs. IT and security worry about the devices those apps run on. Identity connects them: the sign-in is where app, user and device meet a policy.
How should a mobile app sign users in?
With the OAuth 2.0 authorization code flow and PKCE, run in the system browser, as RFC 8252 describes.
- Generate a
code_verifierand S256code_challengeper sign-in. The PKCE Generator shows the format. - Open the authorization URL with
ASWebAuthenticationSession(iOS) or Custom Tabs (Android), never an embedded webview. - Receive the code on a claimed HTTPS link (Universal Links, App Links) or a reverse-domain private scheme.
- Check
state, then exchange the code with the verifier.
The full walkthrough is in integrating OAuth with mobile apps.
How should tokens be handled on the device?
Stored in the keychain or keystore, kept short-lived, rotated or bound to a key, and never logged.
| Token | Storage | Lifetime guidance |
|---|---|---|
| Access token | Memory, or secure storage if needed offline | Minutes to an hour |
| Refresh token | Keychain / Keystore-backed encrypted storage | Rotate on use; revoke on sign-out |
| ID token | Memory; validate then discard | Only needed at sign-in |
Sender-constrained tokens with DPoP (RFC 9449) bind tokens to a key generated on the device, ideally in secure hardware.
How can an API trust the app?
Combine user tokens with app attestation, rate limits and behavior checks.
Anyone can extract an app's client ID and call your API from a script. App attestation (App Attest on Apple platforms, Play Integrity on Android) adds a signed statement that the request comes from your genuine app on a real device. Use it for sensitive operations such as registration, payments and password resets.
How do device controls fit in?
The identity provider asks device management for the device's state and applies policy before issuing tokens.
Corporate devices can be fully managed. For personal devices, Android work profiles, Apple User Enrollment and app protection policies separate work data. Our BYOD security checklist and BYOD in Europe cover policy and privacy.
What are the most common mobile identity bugs?
Webview logins, hardcoded secrets, missing PKCE, tokens in plain storage or logs, and APIs that trust client-side checks.
The OWASP Mobile Application Security Verification Standard (MASVS) and its testing guide are a good checklist for app teams. Check your authorization request in the Authorization URL Builder for the protocol side.
Questions
What is app attestation?
A platform service, such as Apple's App Attest or Google's Play Integrity API, that lets an app produce a signed statement that it is a genuine, unmodified build running on a real device. Your backend verifies the statement before trusting the request.
Is certificate pinning still recommended?
It can help in high-risk apps but causes outages when certificates change and is easy to get wrong. Many teams rely on the platform's default trust plus app attestation and short-lived tokens instead.