Posts

Part 7: Identity Check - Biometric Hardening & User Intent

Image
  Closing the "Shoulder-Surfing" loophole by enforcing Class 3 biometrics and Keystore invalidation in modern Android architecture. In  Part 6 , we mastered the networking lifecycle to ensure our sessions are resilient. But there is a final, physical threat that keeps security architects awake at night:  The “Shoulder-Surfing” or Stolen Phone Scenario. If an attacker learns a user’s PIN and then snatches the device while it’s unlocked, they have  full user-level control of the device . In this state, a standard “is device guarded” check is no longer enough for high-stakes operations. Today, we implement the final frontier of mobile defense:  The Identity Check Pattern. The Mental Model:  Session Authentication $\neq$ Intent Authentication. Being “logged in” is not the same as “authorizing this specific ₹5,00,000 transfer.” ⚡  TL;DR The Problem:  An unlocked device is a compromised device once the PIN is leaked — a common real-world  fraud vec...

Part 6: The Interceptor Pattern - Mastering the Token Lifecycle

Image
 A Staff-level guide to using OkHttp Authenticator and Kotlin Mutex to prevent refresh storms and race conditions in high-scale apps. In  Part 5,  we ensured our app is running on a trustworthy device. But even on a “Strong Integrity” device, your networking layer can still be a source of chaos. If your app makes ten concurrent API calls the moment the user opens it — and their access token has just expired — you don’t want ten separate “refresh token” requests hitting your server. This is a classic  “Refresh Storm”  that leads to race conditions, invalidated sessions, and a frustrated user who is randomly logged out. ⚡  TL;DR The Problem:  Concurrent requests triggering redundant refresh calls (Race Conditions). The Tool:  OkHttp  Authenticator  (Reactive) for 401 handling. The Solution:  A Kotlin  Mutex  to synchronize the "Critical Section" of token renewal. The Impact:  Proper client-side concurrency control preve...