React Native Authentication with Expo Router: Secure Login, Tokens, and Protected Routes

Overview

Authentication in a React Native app is more than a login form. A complete implementation must answer several connected questions: where tokens are stored, how the app restores a session after launch, what happens when an access token expires, how unauthenticated users are redirected, and how an external provider returns control to the app.

Expo Router gives you a useful file-based structure for these decisions, but it does not replace an authentication service or a session model. Your backend or identity provider should remain responsible for validating credentials, issuing tokens, revoking sessions, and enforcing authorization. The mobile app should manage presentation, temporary session state, secure persistence, and navigation.

A durable architecture commonly has five pieces:

• Auth API: endpoints or an SDK for sign-up, login, refresh, logout, and password recovery.
• Session provider: a React context or state store that exposes the current user and session status.
• Secure storage: a platform-backed store for sensitive refresh credentials, such as Expo SecureStore where appropriate.
• Navigation guard: an Expo Router layout that sends users to the correct route based on session state.
• Request layer: a single place that adds access tokens and handles an expired session consistently.

For storage trade-offs, see our comparison of AsyncStorage, MMKV, SecureStore, and SQLite in React Native. Do not treat ordinary key-value storage as a secure vault simply because the value is encoded or obscured.

What to track

Session state and token ownership

Represent the authentication lifecycle explicitly instead of using a single nullable user value. A simple state model might include loading, authenticated, unauthenticated, and error. The loading state prevents the router from redirecting before persisted credentials have been checked.

Keep access tokens short-lived and preferably in memory. Store only the credential needed to obtain a new session in secure storage, and define which component owns each operation. For example, an AuthProvider can own session restoration and logout, while an API client can request a refresh when it receives an authentication failure. Avoid having individual screens read and write tokens directly.

type AuthStatus = 'loading' | 'authenticated' | 'unauthenticated' | 'error';

type Session = {
  accessToken: string;
  user: { id: string; email?: string };
};

// Keep refresh credentials out of ordinary application state.
const [status, setStatus] = useState<AuthStatus>('loading');
const [session, setSession] = useState<Session | null>(null);

Sign-up and login flows

Validate form input before sending it, but let the server remain the authority for account rules. Show field-level errors when possible and use a general message for errors that should not reveal whether an account exists. Disable the submit action while a request is in progress, and make the loading state accessible to screen-reader users.

After successful sign-up, choose a deliberate flow: sign the user in immediately, require email verification, or send them to a verification screen. That decision affects both navigation and session restoration. Keep it in the product contract rather than inferring it from an API response on each screen.

Protected routes with Expo Router

Place public screens, such as sign-in and registration, separately from authenticated screens. A typical structure is:

app/
  _layout.tsx
  (public)/
    login.tsx
    register.tsx
  (app)/
    _layout.tsx
    index.tsx
    settings.tsx

The authenticated layout should render only after the provider has finished restoring the session. Depending on the Expo Router version in your project, you can use the current protected-route configuration or redirect from the layout with a navigation effect. The important rule is the same: do not render private screens while the session is unresolved, and do not rely on a visual redirect alone to protect data.

For route organization and version-specific navigation patterns, use the Expo Router guide for file-based navigation, authentication, and deep linking.

Refresh, logout, and failure handling

Centralize refresh-token handling in the request layer. If several requests fail at once, avoid starting several refresh operations concurrently. A shared refresh promise or queue can allow waiting requests to reuse one refresh result. If refresh fails, clear the in-memory session, remove the persisted credential, and send the user to login.

Logout should revoke the server-side session when the provider supports it, then clear local state regardless of the network result. This prevents a failed network request from leaving a user apparently signed in on the device. Never write access tokens, refresh tokens, authorization codes, or full authentication responses to logs.

Deep-link callbacks

Social login, password recovery, email verification, and magic-link flows may return through a deep link. Register a distinct callback path, validate the returned parameters, and exchange any one-time code on the server or through the provider SDK. Do not treat a token embedded in an incoming URL as safe merely because the URL came from your own app.

Test cold-start links, links received while the app is already open, cancelled authentication, malformed parameters, and links sent to the wrong environment. The related React Native deep linking guide provides additional routing considerations.

Cadence and checkpoints

Authentication is a good candidate for a monthly or quarterly review because SDKs, native configuration, backend policies, and redirect settings can change independently. Keep a small checklist in the repository so the review is repeatable.

• Every code change: test login, logout, session restoration, expired access tokens, and an API request made immediately after login.
• Monthly: review authentication logs for repeated refresh failures, redirect errors, unexpected logout reports, and requests made without credentials.
• Quarterly: verify package versions, iOS and Android redirect configuration, secure-storage behavior, test accounts, and provider settings.
• Before release: test a clean install, an app update, offline startup, background-to-foreground return, and account switching.
• When changing providers: document token formats, expiry behavior, scopes, callback URLs, logout semantics, and error responses before changing the mobile client.

Automate the stable parts of this review with unit tests for the session reducer and request client, integration tests for the auth provider, and device tests for deep links. React Native Testing Library can cover form states and route decisions without requiring every test to perform a real provider login.

How to interpret changes

A rise in login failures does not automatically mean the form is broken. Compare the timing and shape of the failures. A sudden increase after a native build may indicate a redirect or configuration issue. Failures limited to returning users may indicate refresh-token handling or an account migration problem. Failures that occur only after the app resumes may point to stale in-memory access tokens.

Measure the states that help you distinguish these cases:

• Login and registration attempts, grouped by outcome and app version.
• Session restoration duration and the percentage of sessions that cannot be restored.
• Access-token refresh attempts, successful refreshes, and forced logouts.
• Deep-link callbacks received, rejected, expired, or cancelled.
• API requests that receive authentication errors before and after a refresh attempt.

Use privacy-preserving identifiers and avoid collecting credentials or raw callback URLs. A useful authentication metric should help locate a failure without becoming a second source of sensitive data.

Also distinguish authentication from authorization. A valid session does not mean a user may access every record or action. The server must enforce permissions, while the client can hide unavailable controls and provide a clear explanation when an action is denied.

When to revisit

Revisit this implementation whenever you change the identity provider, add social or passwordless login, alter token lifetime, introduce a new redirect, or move from development to a production build configuration. Review it after changing Expo, React Native, native project settings, or secure-storage dependencies as well.

Use this action list before merging an authentication change:

1. Write down the expected session states and the transition that causes each one.
2. Confirm where access and refresh credentials live and which code can access them.
3. Test first launch, app restart, offline launch, token expiry, refresh failure, logout, and account switching.
4. Test deep links on both platforms from a cold start and an already running app.
5. Check that protected API data is still protected if a user bypasses the expected route.
6. Remove sensitive logs and update the quarterly review checklist with any new provider behavior.

Authentication should become less fragile as the app grows, not more distributed. Keep session decisions centralized, keep navigation tied to explicit state, and revisit the integration whenever its surrounding contracts change.