Engineering

Authentication Test Prompt

Login, token refresh, and everything that must fail: expired tokens, wrong permissions, malicious credentials — auth tested as behavior.

Open in Test Case Prompt Generator

Overview

Auth code is tested backwards everywhere: the login-works test exists, the seventeen ways auth must FAIL don't. This setup generates the auth test suite with security as a first-class coverage area: authentication failures (missing, expired, malformed credentials — each its own test), permission boundaries returning the right 403s, malicious input through every credential field, and access to other users' resources by ID rejected — alongside the API failure scenarios: 401 vs 403 distinguished, idempotent refresh behavior, and error shapes that don't leak what exists.

How to use this resource

Count the failure tests

A healthy auth suite has more failure tests than success tests — the contract is built to produce that ratio.
Test expiry as a moment

The token that expires BETWEEN two requests is the scenario that separates tested auth from lucky auth.
Verify the cross-user wall

Authenticated-but-wrong-user requests against every resource type — the test that catches IDOR before users do.

Why This Works

Failure-first framing matches auth reality: success is one path, failure is the surface
The 401/403 separation tests the distinction attackers probe first
Cross-user scenarios catch the authorization bugs authentication tests can't see

Best for

Auth endpoints, middleware, and guards
Systems where a 403 returned as 404 (or worse, 200) is an incident
Token lifecycles with refresh, expiry, and revocation

Not for

Reviewing auth code for vulnerabilities — that's the Code Review Prompt Generator's security focus; review finds, tests verify
Pen-testing — these tests verify specified behavior, not undiscovered attack surface

Use cases

Testing login and token-refresh endpoints before release
Covering expired-token behavior on every protected route
Verifying users can't reach each other's resources by ID

FAQ

How do I generate tests for everything that should fail in auth

The Security and Failure Scenarios areas make failures first-class: missing, expired, and malformed credentials each get their own test, permission boundaries return 403 for the wrong roles, and access to other users' resources by ID is rejected. Test Case Prompt Generator produces the prompt; you run it in your own assistant, and it generates tests only, never modifying the implementation.

Does this prompt test the difference between 401 and 403

Yes, as separate tests. The TEST STRATEGY treats auth as behavior: 401 for missing or expired credentials, 403 for valid-but-forbidden, and they are different tests. The Failure Scenarios also require nonexistent resources to return 404, not 500 or an empty 200, and every response asserts status code, body shape, and the headers that matter.

Is this a substitute for a security review or pen test of my auth code

No. The notFor is explicit: reviewing auth code for vulnerabilities is the Code Review Prompt Generator's job, and pen-testing probes undiscovered attack surface. These tests verify specified behavior, so they close the ASSUMPTIONS and GAPS the prompt lists but don't guarantee your auth is secure; review finds, tests verify, and both stay under human review.

Customize This Resource

Opens this setup in Test Case Prompt Generator. Generate to get the full test contract — then adjust the strategy, framework, coverage, and depth.

Open in Test Case Prompt Generator

Prompt Template

Copy it as-is, or use Open in Test Case Prompt Generator to load it pre-filled and customize it with your own context.

TESTING OBJECTIVE
Test the login and token-refresh endpoints — including everything that must fail.
Strategy: API tests — the contract is the subject: requests, responses, status codes, auth.
Generate tests only — do not modify the implementation.

CODE CONTEXT
[Paste the endpoint under test here]

TEST STRATEGY
- Test the contract, not the implementation: request validation, response shape, and status codes are the spec.
- Every response asserts three things: status code, body shape, and the headers that matter.
- Auth is tested as behavior: 401 for missing/expired credentials, 403 for valid-but-forbidden — and they are different tests.
- Error responses have a contract too — assert their shape as strictly as the success path.

COVERAGE AREAS
Happy Path:
- The primary success path with realistic, typical inputs
- The most common variations users actually exercise
- Expected outputs asserted precisely — values and shape, not just "no exception"
Error Handling:
- Every declared error path actually triggers in a test
- Errors carry the right type, message, and code
- Failures leave state clean — no partial writes survive
- Errors propagate or are swallowed exactly as specified
Security:
- Authentication failures: missing, expired, and malformed credentials
- Permission boundaries: the right operations return 403 for the wrong roles
- Malicious input: injection attempts in every text field
- Access to other users' resources by ID is rejected

FAILURE SCENARIOS
Each of these gets at least one test:
- Invalid payloads return 400 with the documented error shape — not 500
- Missing or expired auth returns 401; wrong permissions return 403
- Nonexistent resources return 404, not 500 or an empty 200
- A duplicate of a completed request behaves as specified (idempotency)
- Oversized payloads are rejected at the documented limit

TEST DATA GUIDANCE
- Use realistic, production-shaped data — names, amounts, and dates that could exist.
- Build complex objects with builders or factories, not hand-assembled literals repeated per test.
- Name boundary data for its intent (maxLengthName, expiredToken), not its value.
- Never share mutable fixtures between tests.

FRAMEWORK GUIDANCE
Framework: Generic.
- Use the project's existing test framework and follow its established conventions.

OUTPUT FORMAT
- Return one complete, runnable test file.
- Group tests by coverage area, with a comment header per group.
- Each test: arrange-act-assert structure, one behavior per test.
- Cover every selected coverage area systematically — each coverage item above gets at least one test.
- Parametrize repetitive cases instead of copy-pasting tests.
- Name tests so a failure message alone identifies the broken behavior.

ASSUMPTIONS
- After the tests, list every assumption you made about unspecified behavior under an ASSUMPTIONS heading.
- Where the code's intent is ambiguous, test the most likely intent and flag the ambiguity.
- List GAPS: behaviors you could not test with the information given.

NON-GOALS
- Do not rewrite or "improve" the implementation code — test it as it is.
- Do not refactor the architecture to make it more testable; flag testability problems instead.
- Do not invent requirements — test only specified or clearly implied behavior.
- Do not weaken assertions to make tests pass.

More resources from Test Case Prompt Generator

Resource

Playwright Test Prompt

getByRole over CSS chains, auto-wait over sleep, web-first assertions — Playwright tests written the way Playwright wants.

Engineering

Resource

Unit Test Prompt — Isolation Done Right

Mock the dependencies, test the business logic, one behavior per test — the unit testing contract that bans plumbing tests.

Engineering

Resource

Agent Safety & Refusal Evaluation Prompt

Test the two failure directions — does the agent refuse what it must, and does it stay helpful on the benign requests it shouldn't over-refuse?

AI Agents

Resources that pair well

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Debugging Prompt — the Investigation Contract

"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.

Prompt Engineering

Resource

Fix Invalid JSON from AI

The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.

Engineering

Related tools

Tool

Test Case Prompt Generator

Build test generation prompts — unit, integration, or E2E — with framework modes and edge-case coverage rules.

Coding Workflows

Workflows that use this resource

Workflow

AI Security Review Workflow

Review code for what an attacker would do, not just what tests catch — anchor the model as a security engineer, run a threat-focused review, then back the findings with auth and input tests.

3 steps 30–50 minutes

Guides for this resource

Guide

How to Review Authentication Code With AI Without Missing Common Flaws

Four hundred lines of login code and a yes-or-no. You can read every line, find nothing, and still be wrong — because what will hurt you is in the file nobody opened alongside it: a session that outlives a logout, a reset that leaves the old one working.

Software Development with AI

Tip: Save time by exploring related resources and tools that integrate with this resource.