How Apirex detects auth in any codebase

Auth is the messiest part of any web app. Every codebase rolls it differently — some use Clerk, some hand-roll JWT, some have a five-year-old express-session setup nobody wants to touch. Apirex has to recognize all of them and translate them to native.

What we look for#

Three signals: package.json dependencies, network call patterns, and route guards. If we see @clerk/nextjs, that's Clerk. If we see Authorization headers with Bearer tokens, that's JWT. If we see calls to supabase.auth.signIn, that's Supabase Auth. Firebase Auth and Auth0 follow similar fingerprints. Each signal has a confidence score; we combine them.

The hard cases#

Custom auth — someone's hand-rolled session cookie with a /me endpoint. We detect this from the call graph: any endpoint that returns user data without an explicit Authorization header is probably session-based. We then map it to an `OkHttp` CookieJar interceptor in Android.

What we generate#

On the native side: a TokenStore (DataStore-backed for JWT, CookieJar for sessions), an OkHttp interceptor that attaches credentials, a polished onboarding flow with the right buttons (Google, email, SSO, etc.), and biometric unlock for returning sessions.

Why this matters#

Wrong auth means a broken app. We treat detection as a first-class problem because the difference between 'native app' and 'app that logs you out every five minutes' is exactly this code path. See how it fits into the rest of the pipeline in our architecture overview.