Auth Tokens & Idempotency Interview Questions
DATA › Networking
How would you unit-test a single-flight token refresh implementation to prove that 20 concurrent callers only trigger one network refresh call?
What a strong answer covers: You'd fake the refresh network call with something you can count invocations on and optionally suspend indefinitely until released, then launch 20 coroutines against the accessor concurrently (using a test dispatcher/runTest so they're all genuinely in-flight together rather than serialized), release the fake refresh, and assert both that the mock was invoked exactly once and that all 20 callers received the same resulting token. The trap is writing a test where the coroutines don't actually overlap because the test dispatcher runs them sequentially, which would pass even on a broken implementation that fires N refreshes.
Your app runs a widget or a separate :service process alongside the main app process, and both need a valid access token. How does an in-memory single-flight refresh strategy break down here, and what would you do instead?
What a strong answer covers: An in-memory Mutex/Deferred only coordinates coroutines within one process's memory space, so a separate process has its own copy of the token manager and can independently kick off a refresh at the same time, defeating single-flight and potentially racing against rotation if the server invalidates the old refresh token on use. The fix is moving coordination to something shared across processes, like a ContentProvider, a file lock, or funnelling all refresh through a single foreground process (often the main app) that other processes request tokens from via IPC/Binder rather than each holding their own refresh logic.
A security review flags that the access token sits in memory as a plain Kotlin String for the life of the app, and Strings aren't securely wiped from memory. How seriously do you take that, and what would you actually change, if anything?
What a strong answer covers: It's a real but low-severity finding for most apps: an access token is short-lived, scoped, and revocable, so the practical risk is a rooted device or a memory-dump attack in the narrow window before expiry, which is a much smaller attack surface than the refresh token's storage. A strong answer prioritizes accordingly, hardening refresh-token storage (Keystore-backed, never plaintext) and rotation over trying to zero out access-token Strings in memory, and pushes back on treating both tokens as equally sensitive when they're not.