How to Test Authentication and Authorization with Mock APIs

Authentication Scenarios Every Frontend Should Test

Cover the full login and session lifecycle, not only the happy path:

• Successful login: tokens stored, user profile loaded, redirect to the intended page.
• Invalid username or password: field-level or form-level messaging without leaking whether the email exists.
• Missing required fields: client validation and server validation both produce recoverable UI states.
• Locked or disabled account: clear copy and no silent retry loop.
• Multi-factor authentication required: challenge step renders and can be cancelled safely.
• Expired session: protected calls fail and the user is guided back to login.
• Invalid access token: malformed or revoked tokens are treated as unauthenticated.
• Failed token refresh: session clears and the user is not stuck mid-flow.
• Logout and revoked session: local state is wiped and subsequent protected requests fail cleanly.

Authorization Scenarios Every Frontend Should Test

Once identity is known, verify permission boundaries:

• Authenticated user with permission sees the resource and allowed actions.
• Authenticated user without permission sees an access-denied state, not a blank page.
• Anonymous users hitting protected routes are redirected or challenged to sign in.
• Role-based access maps correctly for viewer, editor, and admin personas.
• Resource ownership prevents users from editing another user's records.
• Admin-only actions stay hidden or disabled for non-admins, and the API denial is handled.
• Tenant or workspace isolation keeps data from leaking across organizations.

Pair these checks with HTTP status codes every frontend developer should test so status handling stays consistent across screens.

Understanding 401 Versus 403

Mixing these codes leads to the wrong UX. Treat them as different product states:

• 401 Unauthorized usually means authentication is missing or invalid.
• 403 Forbidden means the identity may be known, but access is not allowed.

Build Mock Authentication Response Profiles

Create one mock endpoint for login or session checks, then define multiple response profiles you can switch during testing. Useful profiles include:

• Login success: 200
• Invalid credentials: 401
• Forbidden role: 403
• Validation failure: 422
• Rate limited login: 429
• Identity-provider failure: 500 or 503

Example success response:

{
  "user": {
    "id": "usr_123",
    "name": "Maya Cohen",
    "email": "maya@example.com",
    "role": "editor"
  },
  "accessToken": "mock_access_token",
  "expiresIn": 3600
}

Example invalid-credentials response:

{
  "error": {
    "code": "INVALID_CREDENTIALS",
    "message": "The email or password is incorrect."
  }
}

For identity-provider outages, also rehearse delays and retries. See how to test API timeouts, retries, and network failures.

Frontend Implementation Example

The UI should handle loading, success, validation, invalid credentials, forbidden access, and generic server failure. This TypeScript example uses fetch against a mock login endpoint:

type LoginResult =
  | { status: "success"; user: { id: string; role: string } }
  | { status: "invalid_credentials"; message: string }
  | { status: "forbidden"; message: string }
  | { status: "validation"; message: string }
  | { status: "server_error"; message: string };

export async function loginWithPassword(
  email: string,
  password: string
): Promise<LoginResult> {
  if (!email || !password) {
    return { status: "validation", message: "Email and password are required." };
  }

  const response = await fetch("https://mock.example.com/auth/login", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ email, password }),
  });

  if (response.status === 401) {
    const body = await response.json();
    return {
      status: "invalid_credentials",
      message: body.error?.message ?? "Invalid credentials.",
    };
  }

  if (response.status === 403) {
    return { status: "forbidden", message: "You do not have access." };
  }

  if (response.status === 422) {
    return { status: "validation", message: "Check the submitted fields." };
  }

  if (!response.ok) {
    return { status: "server_error", message: "Login is temporarily unavailable." };
  }

  const data = await response.json();
  return { status: "success", user: data.user };
}

Testing Protected Routes

Protected routes should cover loading while the session is checked, redirect for anonymous users, access-denied UI for insufficient permissions, and the correct page for authorized users. A React-style sketch:

function ProtectedPage({
  session,
  requiredRole,
}: {
  session: { status: "loading" | "anonymous" | "authenticated"; role?: string };
  requiredRole: string;
}) {
  if (session.status === "loading") {
    return <p>Checking your session…</p>;
  }

  if (session.status === "anonymous") {
    // In Next.js App Router, redirect("/login") from a server component
    // or use router.replace("/login") in a client effect.
    return <p>Redirecting to login…</p>;
  }

  if (session.role !== requiredRole) {
    return <p role="alert">You do not have permission to view this page.</p>;
  }

  return <p>Welcome to the editor workspace.</p>;
}

For React and Next.js mock wiring patterns, see how to use mock APIs in React and Next.js applications.

Testing Token Expiration and Refresh Failure

Expired access tokens are common in long-lived SPAs. A realistic sequence to mock:

1. An API call returns 401.
2. The client calls a refresh endpoint.
3. The refresh endpoint also fails.
4. The frontend clears the session.
5. The user is redirected to login with a useful message.

async function fetchWithSession(input: RequestInfo, init: RequestInit = {}) {
  let response = await fetch(input, { ...init, credentials: "include" });

  if (response.status !== 401) {
    return response;
  }

  const refreshed = await fetch("/auth/refresh", { method: "POST", credentials: "include" });

  if (!refreshed.ok) {
    clearLocalSession();
    window.location.assign("/login?reason=session_expired");
    throw new Error("Session expired");
  }

  response = await fetch(input, { ...init, credentials: "include" });
  return response;
}

Mock the first endpoint as 401 and the refresh endpoint as 401 or 503 so you can verify the redirect and messaging without waiting for a real token clock to expire.

Security Caveat

Mock APIs test client behavior. They do not prove the security of a production authentication system. Mocks cannot demonstrate that:

• Password storage is secure
• Tokens are correctly signed
• Backend authorization rules are enforced
• Sessions cannot be hijacked
• Real identity-provider configuration is correct

Use mocks to harden UX and client state machines. Use security reviews, penetration testing, and backend tests for the actual trust boundary.

Practical Checklist

Verify these authentication and authorization states before production:

• Successful login stores session data and lands on the intended route
• Invalid credentials show safe, actionable feedback
• Missing fields fail locally and via server validation
• Locked or disabled accounts are explained clearly
• MFA challenge and cancel paths work
• Expired and invalid tokens trigger login recovery
• Refresh failure clears state and redirects once
• Logout removes tokens and blocks protected APIs
• Anonymous users cannot stay on protected pages
• Insufficient roles show access denied, not empty layouts
• Admin-only and ownership rules are visible in the UI and enforced by mocked APIs
• Tenant isolation prevents cross-workspace data display

For a wider release checklist, use the complete API testing checklist for frontend teams.

Using MockFlow for Auth Scenarios

MockFlow response profiles help you switch quickly between status codes, headers, bodies, and delays for the same auth endpoint. That makes it practical to rehearse login success, invalid credentials, forbidden roles, validation failures, rate limits, and identity outages in one session.

MockFlow does not validate real JWT signatures or act as a complete identity provider. Use it to exercise frontend handling of authentication and authorization responses while the real auth service is still evolving. Guest mode works locally without an account; logged-in users can use shareable mock API URLs when teammates need the same scenarios.

Related reading: how to simulate API responses for frontend development and how to mock API responses without building a backend.