Mobile Security in the Context of IAM

How does it starts?

Protecting access tokens on mobile devices is critical to prevent unauthorized access and token theft — especially since tokens grant access to sensitive APIs and data.

Here’s how mobile platforms (iOS and Android) secure access tokens stored on the device:

🔐 1. Secure Storage Mechanisms

✅ Android

• EncryptedSharedPreferences or EncryptedFile (from Jetpack Security)
• Android Keystore System:
  
  • Generates & stores cryptographic keys in hardware-backed secure elements (e.g., TEE)
  • Used to encrypt/decrypt tokens
  • Keys are app-specific and non-exportable

✅ iOS

• Keychain Services:
  
  • Secure storage area for sensitive data (like tokens)
  • Encrypted and hardware-protected (Secure Enclave on newer devices)
  • Data is sandboxed per app and optionally protected with Face ID / Touch ID

🧠 2. Token Encryption and Obfuscation

• Tokens are encrypted before storing
• Some apps split tokens or store partial values in multiple places
• Use of symmetric or asymmetric encryption to protect tokens using keys stored in the Keychain/Keystore

🕵️‍♂️ 3. Secure Session & Token Handling

• Short-lived access tokens + refresh tokens with strict expiry
• Refresh tokens often stored more securely (or not at all if not needed)
• In-memory tokens: Access tokens may be kept in RAM only during a session to avoid persistent storage altogether

🧱 4. Runtime and Anti-Tamper Protections

• Root/Jailbreak Detection: Prevents the app from running on compromised devices
• Code Obfuscation: Makes reverse engineering of token-handling logic harder
• Certificate Pinning: Ensures tokens are only transmitted to trusted servers
• Biometric Unlock for secure areas of the app before token access
  

✅ Summary: Defense-in-Depth for Token Security on Mobile

🔄 Authentication Flow

1. User authenticates
2. Access + refresh tokens received
3. Tokens are encrypted using a key from Keystore/Keychain
4. Encrypted token stored securely
5. App decrypts and uses token when needed
6. Token is refreshed silently when it expires

📱 How ROPC Works in Mobile (OIDC Context)

🔁 Step-by-Step Token Flow

1. User Login Form
   The mobile app presents a custom UI (not a system browser) asking for username and password.
2. App Sends Credentials to the Authorization Server (AS)
   The app sends a token request to the /token endpoint:
3. http POST /token
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=password
   username=john.doe
   password=correcthorsebatterystaple
   client_id=mobile-app
   client_secret=xyz123 ← only if it's a confidential client
   scope=openid profile email
   
4. Authorization Server Authenticates the User
   • Validates credentials
   • May enforce MFA, risk signals, or device context
   • Optionally uses a custom Authentication Context Class (ACR) in OIDC
5. Tokens Issued
   On success, the AS issues:jsonCopyEdit{
"access_token": "eyJhbGci...abc",
"id_token": "eyJ0eXAi...xyz",
"expires_in": 3600,
"token_type": "Bearer",
"refresh_token": "abc123..."
}
   
   • ✅ ID Token – JWT with user claims
   • ✅ Access Token – for accessing APIs
   • ✅ (Optional) Refresh Token – if offline access is requested

🔒 Security Considerations for ROPG on Mobile

✅ When to Use ROPG (if at all)

• First-party mobile apps
• Legacy systems where modern flows aren’t feasible
• Internal use only
• In combination with:
  • Strong device attestation
  • Root detection
  • Rate limiting and anomaly detection

❗ Better Alternatives

Modern OAuth/OIDC recommends using:

🔁 Authorization Code Flow with PKCE

• Uses a system browser or in-app browser (ASWebAuthenticationSession)
• Redirects user to the IdP
• Does not handle passwords directly
• More secure and user-friendly