Authentication Patterns for Mobile Apps

Authentication in Mobile Context

Mobile authentication presents unique challenges compared to web:

• Users expect to stay logged in for weeks or months (no session expiration on every browser close)
• Typing passwords on mobile keyboards is painful, driving demand for passwordless flows
• Secure token storage must survive app restarts and OS updates
• Biometric sensors (Face ID, Touch ID, fingerprint) provide convenient, secure alternatives
• Apple requires "Sign in with Apple" if you offer any social login

Common Authentication Flows

Email/Password

The classic approach. The user registers with an email and password, then logs in with the same credentials.

• Implement on your own backend or use a service (Firebase Auth, Supabase Auth, Auth0)
• Always hash passwords server-side (bcrypt, argon2)
• Require minimum password strength
• Support "forgot password" flow via email
• Consider rate limiting and account lockout for brute-force protection

Social Login (OAuth 2.0)

Let users sign in with existing accounts from Google, Apple, Facebook, X, or others.

The flow typically works like this:

1. User taps "Sign in with Google"
2. App opens the provider's auth screen (system browser or native SDK)
3. User authenticates and grants permission
4. Provider returns an authorization code or ID token to your app
5. Your app sends this to your backend
6. Backend verifies the token with the provider and creates/finds the user account
7. Backend issues your own access token and refresh token

Sign in with Apple

Required by Apple if your app offers any third-party login. Key details:

• Uses Apple's native authentication UI
• Users can choose to hide their email (Apple provides a relay address)
• Returns a JWT ID token on first sign-in with user info
• Subsequent sign-ins only return the user identifier (not the name/email)
• Your backend must verify the token with Apple's public keys

Magic Link / OTP

Passwordless authentication:

• Magic link: Send a one-time login URL to the user's email
• OTP (One-Time Password): Send a 6-digit code via SMS or email
• User taps the link or enters the code to authenticate
• No password to remember, no password to steal
• SMS OTP has security concerns (SIM swapping) but remains popular for convenience

Passkeys

The newest standard, supported by both Apple and Google since 2023:

• Based on FIDO2/WebAuthn standards
• Uses device biometrics to authenticate
• No passwords at all
• Synced across devices via iCloud Keychain (Apple) or Google Password Manager
• Phishing-resistant by design
• Adoption is growing but not yet universal

Token Management

JWT (JSON Web Tokens)

The standard format for mobile auth tokens:

• Access token: Short-lived (15 minutes to 1 hour), used for API requests
• Refresh token: Long-lived (weeks to months), used to get new access tokens

Token Storage

Where you store tokens is critical for security:

• iOS Keychain: The only appropriate place for sensitive tokens on iOS. Encrypted by the OS, persists across app reinstalls (if configured), supports biometric access control.
• Android Keystore + EncryptedSharedPreferences: Store encryption keys in the hardware-backed Keystore, encrypt tokens before saving to SharedPreferences.
• Expo SecureStore: Cross-platform wrapper around iOS Keychain and Android Keystore.
• React Native Keychain: Community package wrapping platform-specific secure storage.

Never store tokens in AsyncStorage, UserDefaults, SharedPreferences (unencrypted), or local files. These are not secure.

Token Refresh Flow

1. App makes an API request with the access token
2. Server returns 401 (token expired)
3. App automatically sends the refresh token to get a new access token
4. App retries the original request with the new access token
5. If the refresh token is also expired, redirect to login

Implement this as an HTTP interceptor (Axios interceptor, Ktor plugin, Dio interceptor) so individual API calls do not need to handle refresh logic.

Biometric Authentication

Face ID, Touch ID (iOS), and fingerprint/face unlock (Android) enhance security and convenience:

• Used as a second factor or as a way to unlock stored credentials
• The biometric check happens entirely on device; the biometric data never leaves the device
• Gate sensitive actions (payments, profile changes) behind biometric confirmation
• Always provide a fallback (PIN, password) for devices without biometric hardware

Session Management

• Support multiple devices per account
• Provide a "sign out of all devices" option
• Track active sessions and show them to the user
• Invalidate tokens server-side on password change
• Handle the case where a token is revoked while the app is in use

Best Practices

• Use HTTPS for all authentication endpoints (no exceptions)
• Implement certificate pinning for high-security apps
• Store tokens in platform-secure storage only
• Minimize token lifetime and use refresh tokens for longevity
• Rate-limit authentication endpoints to prevent brute force
• Log authentication events for security monitoring
• Support account deletion (required by both Apple and Google)

Related Topics

• Expo: The React Native Platform for Fast Development
• Rate Limiting and API Security for Mobile Backends
• Apple App Review Guidelines: What Every Developer Needs to Know