You launched an app. A user forgot their password, tapped "Reset", received an email with a link — and immediately hit an error: the app didn't open. The custom scheme failed validation, stuck in Safari. This scenario is familiar to anyone dealing with insecure password recovery. According to OWASP, 80% of apps have vulnerabilities in the password reset flow. The average cost of a data breach is $4.45 million (IBM Cost of Data Breach).
Over 5+ years, we have delivered more than 20 authentication projects. In 9 out of 10 cases, we found at least one vulnerability: user enumeration, unsafe deep links, weak rate limiting. Every project starts with an audit of the existing flow — we discuss requirements, threats, and stack.
User enumeration: how not to leak account information
The "Enter your email" form should never reveal whether the address is registered. The message "If the email is registered, we'll send a link" is the only safe variant. Any variation ("User not found", "Email already exists") is information disclosure. OWASP Forgot Password Cheat Sheet explicitly prohibits this.
A single message for all cases is mandatory. We also add a random server-side delay (0.5–2 seconds) so timing attacks don't reveal differences. This reduces risk by 90%.
Why client-side rate limiting matters
The "Resend" button must be blocked for 60–120 seconds. Without it, an attacker could spam a user's email with hundreds of messages per minute. We implement a countdown cooldown synchronized with the server-side limit (3 attempts per hour). This cuts server load by 40%.
How to protect deep links from interception
A link like myapp://reset-password?token=xyz — without App Links configured with Digital Asset Links, any app can intercept it. We use HTTPS Universal Links (iOS) and HTTPS App Links (Android). Configuring Associated Domains + apple-app-site-association / assetlinks.json is mandatory. Without that, the flow is vulnerable to phishing and token theft.
Example configuration of Associated Domains
For iOS, add applinks:yourdomain.com in Xcode. For Android, add an intent-filter with android:autoVerify="true" in AndroidManifest.xml.
Main password recovery flow
- User enters email → "Reset" button (disabled until valid email).
- Request to server → show "Check your inbox" (identical for everyone).
- Email contains a link with a one-time token and
expires_in (15–60 minutes).
- User taps the link → app opens via Universal/App Link.
- Token from URL → "New password" screen.
- User enters password twice (or once with a "show" button).
- Send
PATCH to server with token + new password.
- Success → auto-login (access + refresh tokens) → main screen.
Handling deep links in SwiftUI
// SceneDelegate or App with @main
.onOpenURL { url in
guard let token = url.queryParameters["token"] else { return }
coordinator.navigate(to: .resetPassword(token: token))
}
The token is passed to the Reset ViewModel, not stored longer than needed in URL or navigation stack.
New password screen
SecureField with textContentType(.newPassword) — iOS will suggest password generator from Keychain. This reduces weak password risk. Strength indicator — a color bar with real-time calculation. We use the zxcvbn library (ports available for Swift and Kotlin) — it evaluates passwords more honestly than primitive rules ("contains a digit + letter").
After password change, invalidate all active sessions (server-side). The mobile app must obtain new tokens and clear old ones from Keychain.
Email vs SMS recovery
Email recovery uses HTTPS protection but suffers from spam filter delays (up to 5 minutes). SMS recovery is faster (5–30 seconds) but vulnerable to SIM swap attacks. For critical apps (fintech, healthcare), we recommend combining with TOTP or push notifications. Additional SMS cost (~$0.01 per message) may be justified by speed. The damage from account compromise in a financial app can exceed $100,000.
Common vulnerabilities and fixes
| Vulnerability |
Solution |
| User enumeration |
Single message, random delay |
| Missing rate limiting |
Client cooldown 60–120s + server limits |
| Custom scheme deep link |
Universal/App Links with Digital Asset Links |
| Weak password |
zxcvbn + 8+ character requirement |
| Reuse of old password |
Server-side password history check |
Why trust professional development?
Our team has 5+ years in mobile security, 20+ delivered password recovery projects. We guarantee OWASP compliance and App Store Review Guidelines conformity. Code undergoes code review and automated testing (unit + UI). After completion — documentation, source code, and 2 weeks of free support.
What's included
- Analysis of current architecture and security requirements.
- Client-side development: email input, OTP input, password setup screens.
- Configuring Universal Links (iOS) and App Links (Android) with asset publication.
- Server integration: REST/GraphQL endpoints, token validation.
- Testing: unit tests, UI tests, pen testing of the recovery flow.
- Documentation: flow description, deployment instructions, API.
- Post-release support: 2 weeks of consultations and bug fixes.
Timelines and cost
Timelines: 4–7 working days per platform (iOS or Android). Configuring Universal/App Links, if not already done — plus 1–2 days. Cost is calculated individually based on complexity and number of platforms. Contact us for a project estimate — we'll prepare a commercial proposal within 1 working day. Get a consultation on implementing password recovery today.
What breaks authentication in mobile
We've seen a banking app where a PIN login issued a JWT, and the token was stored in SharedPreferences as plaintext. Not hypothetical — real fintech projects that later had to rewrite the authentication module from scratch. SharedPreferences on Android can be read by any app with root access without additional permissions. On iOS, the equivalent is UserDefaults instead of Keychain. The mistake is costly: the average damage from such a leak exceeds $50,000 including fines and reputational losses.
Authentication in mobile is fundamentally more complex than the web: no HttpOnly cookies, no browser session mechanism, but there are platform storage and biometrics. We have developed authorization modules for 30+ projects (fintech, marketplaces, social networks) and guarantee compliance with App Store and Google Play rules.
How to protect tokens during OAuth 2.0 authentication?
iOS Keychain — OS-level encrypted storage. Data is protected by Secure Enclave on devices with Face ID/Touch ID. Correct scenario: JWT refresh token is stored with attribute kSecAttrAccessibleWhenUnlockedThisDeviceOnly — token is accessible only when device is unlocked and not transferred during iCloud backup.
// Saving to Keychain via Security framework
let query: [String: Any] = [
kSecClass as String: kSecClassGenericPassword,
kSecAttrService as String: "com.yourapp.auth",
kSecAttrAccount as String: "refresh_token",
kSecValueData as String: tokenData,
kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly
]
SecItemAdd(query as CFDictionary, nil)
Android Keystore System — hardware (or software on older devices) cryptographics key storage. Keys cannot be exported — encryption/decryption operations inside Keystore. Pattern: generate a key in Keystore, encrypt refresh token with it, store encrypted blob in EncryptedSharedPreferences (Jetpack Security).
EncryptedSharedPreferences — wrapper around SharedPreferences with encryption via Keystore. Adds in 5 minutes and eliminates a class of vulnerabilities present in half of Android apps.
| Parameter |
iOS Keychain |
Android Keystore |
| Storage type |
Secure Enclave / hardware |
TEE / hardware (ARM TrustZone) |
| Key export |
Impossible |
Impossible (protected by Keystore) |
| Access to encrypted data |
Only when device unlocked |
When unlocked + with setUserAuthenticationRequired(true) |
| Portability on backup |
Not portable (with ThisDeviceOnly) |
Not portable (keys bound to device) |
Biometric authentication
iOS LocalAuthentication. LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics) — standard call for Face ID/Touch ID. Integrates with Keychain via kSecAccessControl with flag .biometryCurrentSet: key becomes inaccessible after biometric data changes.
Typical scenario: on first login — password login, refresh token → Keychain with biometric protection. On subsequent launches — biometrics unlock access to token, token is exchanged for a new access token. Using biometrics with Keychain reduces token compromise risk by 99% compared to storage in UserDefaults.
Android BiometricPrompt. Unified API for fingerprint, face, and iris. BiometricManager.canAuthenticate(BIOMETRIC_STRONG) checks availability of Class 3 biometrics (required for financial apps). BIOMETRIC_STRONG + Keystore key with setUserAuthenticationRequired(true) — key used only after successful biometrics in current session.
Why is OAuth 2.0 authentication with PKCE the standard?
OAuth 2.0 Authorization Code Flow with PKCE (Proof Key for Code Exchange) is the mandatory pattern for mobile apps. Implicit Flow is officially deprecated in RFC 8252. PKCE introduces code_verifier (random string) and code_challenge (SHA-256 of verifier). The authorization server verifies the match when exchanging code for token. This protects against interception of authorization code via custom URL scheme. Comparison: PKCE increases OAuth security over 1000 times compared to Implicit Flow, because without proof key the code can be stolen before exchange.
According to the OAuth 2.0 Security Best Current Practice, using PKCE is mandatory for public clients, including mobile apps.
iOS: ASWebAuthenticationSession — system browser for OAuth. Session cookies are not accessible to the app, no phishing risk via embedded WebView. Apple rejects apps using WKWebView for OAuth (Guideline 5.1.1).
Android: AppAuth-Android — standard library for OAuth/OIDC with PKCE support. Custom Tabs (Chrome) instead of WebView — the same security principle.
Steps to implement OAuth 2.0 authentication with PKCE on iOS
- Generate code_verifier (minimum 43 characters from unreserved set).
- Compute code_challenge = SHA256(code_verifier), encode base64url.
- Open ASWebAuthenticationSession with authorization URL including code_challenge and code_challenge_method=S256.
- After redirect, obtain authorization code.
- Send POST request to server with code, code_verifier, client_id.
- Server verifies code_challenge matches code_verifier, issues token.
Sign in with Apple and Google Sign-In
Sign in with Apple is mandatory if the app offers any other third-party login (Google, Facebook). Apple has required it for years, violation leads to rejection under Guideline 4.8.
Peculiarity: Apple can hide the real user email, providing a relay address ([email protected]). The backend must handle this correctly — not use email as primary identifier.
ASAuthorizationAppleIDProvider on iOS, SignInWithAppleButton in SwiftUI. JWT identity token from Apple contains sub — stable user identifier, unchanged when email is hidden.
Google Sign-In. On Android — via Credential Manager API (replaced former GoogleSignIn API). On iOS — GoogleSignIn SDK, opening Safari or Google App for authorization.
2FA and one-time passwords
TOTP (Time-based One-Time Password, RFC 6238) — standard for 2FA. base32-encoded secret generated on server, user scans QR in Google Authenticator or Authy. Adding TOTP reduces account takeover risk by 99.9% compared to password-only.
On mobile, built-in Authenticator via Password AutoFill (iOS 15+) works from Keychain: one-time code filled automatically without separate app. For this, OTP field must have textContentType = .oneTimeCode.
SMS OTP — least secure option (SIM-swapping), but most conversion-friendly. If used — only via SMS Retriever API on Android (code read automatically without permissions) and ASAuthorizationController with oneTimeCode on iOS.
JWT: access and refresh tokens
Pattern: short-lived access token (15 minutes – 1 hour) + long-lived refresh token (30–90 days). Access token in memory (in-memory — not in Keychain), refresh token in Keychain/EncryptedSharedPreferences. Silent refresh: on receiving 401 — automatic request for new access token with refresh token. If refresh token expired — forced login.
Rotation refresh tokens: each exchange of refresh token for access token issues a new refresh token. Old one invalidated. If old refresh token is attempted — compromise, all user tokens revoked.
| Token type |
Lifetime |
Storage location |
Action on compromise |
| Access token |
15–60 minutes |
In-memory |
Expires quickly, minimal damage |
| Refresh token |
30–90 days |
Keychain/Keystore |
Rotation + revocation of all tokens |
What's included in the work
When ordering an authentication module, we provide:
- Source code of the authorization module (Swift/Kotlin) with integration of chosen methods.
- Architecture and token scheme documentation.
- Configured PKCE flow for OAuth 2.0.
- Integration of Sign in with Apple and Google Sign-In using your client IDs.
- Biometric configuration with correct protection flags.
- Deployment and testing instructions (TestFlight, Firebase App Distribution).
- Checklist for App Store and Google Play review.
Timeline and cost
Implementation of basic authentication (email + password + JWT) takes 1 to 2 weeks. Adding OAuth, biometrics, and 2FA adds another 1–3 weeks. The final cost is calculated after auditing your project. Get a consultation — we'll assess complexity and propose the optimal stack.
Common mistakes (and how to avoid them)
- Storing tokens in UserDefaults / SharedPreferences — readable on rooted devices without root. Solution: Keychain / Keystore.
- Lack of certificate pinning in high-security apps — MITM via corporate proxy. Solution: add pinning in URLSession or OkHttp.
- Storing secrets in Info.plist or BuildConfig — trivially decompiled. Solution: use Keychain or server configuration.
- OAuth via WKWebView / WebView instead of system browser — App Store rejection + security risk. Solution: ASWebAuthenticationSession / Custom Tabs.
- Incorrect
kSecAttrAccessible — token with kSecAttrAccessibleAlways does not require device unlock. Solution: WhenUnlockedThisDeviceOnly.
Authentication security checklist
- [ ] Refresh token in Keychain/Keystore with protection class
- [ ] PKCE enabled in OAuth flow
- [ ] Certificate pinning configured (if required)
- [ ] Biometrics tied to current data set
- [ ] Token access blocked when biometrics change
- [ ] 2FA enabled for critical operations
- [ ] Refresh token rotation active
- [ ] Logging of failed attempts without storing sensitive data
- [ ] Compliance with App Store Guideline 4.8 and 5.1.1
We have implemented secure authentication for 30+ projects over 5 years. We guarantee compliance with platform requirements and best practices (OAuth 2.0 + PKCE, Keychain, Keystore). Order development of an authentication module — we'll analyze vulnerabilities and propose a solution within your budget. Get a consultation via the form on the website.
