Authentication Testing: Credential and Session Lifecycles

Authentication testing follows the proof of a user’s identity through challenges, sessions, recovery, expiry, and revocation. It asks which state the service should recognize after each event and what evidence would establish that state. Identity verification is separate from deciding what an authenticated user may do.

Why this Skill is needed

A successful login screen says little about what happens to an earlier session after logout, whether an expired link can create a new session, or how a recovery route relates to multi-factor authentication. Those questions depend on the product’s rules; familiar security conventions are not a substitute for supplied policy.

What the Skill does

The Authentication Testing Skill organizes evidence-bounded scenarios around credentials, identity states, failure paths, and lifecycle. It can prepare reviewable validation candidates from redacted requirements, token metadata, session records, audit events, and existing reports.

Awesome QA Skills: https://github.com/naodeng/awesome-qa-skills organizes Skills by language and testing stage. The series overview: https://inaodeng.com/en/blog/ai-testing/introduction_of_awesome_qa_skills/ explains the shared installation model; this guide focuses on identity verification and credential lifecycle.

Use the states supported by the supplied authentication mechanisms. A password, email link, MFA challenge, federated assertion, or recovery token can have different rules, so do not invent which methods are mandatory or how long they remain valid.

Event or state	Evidence to compare	Question to resolve from policy
Unauthenticated → challenged	Challenge issued, recipient or factor, request context	Which mechanism and trigger apply?
Challenged → authenticated	Server-side state and newly issued session or token metadata	What counts as a completed challenge?
Authenticated → expired, locked, or revoked	Current session state and validity of earlier credentials	Which event ends or restricts this identity?
Recovery → authenticated	Recovery proof, replacement credential, notification, audit event	Which controls apply to recovery and how does recovery close?

The source Skill also calls for creation, rotation, expiry, revocation, and replay rules. Compare the service’s authentication state, token issuance, and old-credential validity after each supplied event. Keep authentication separate from authorization: a valid identity does not prove that a payout change or other resource action is permitted.

Audit the evidence before modeling a risk

The Prompt requires six input states. For authentication, the gaps often concern a policy, state transition, or evidence source.

State	Example	How to handle it
known	A versioned requirement defines an MFA challenge before changing a payout account	Cite the requirement and its effective version
missing	Token lifetime, link reuse, or logout behavior is unspecified	Leave the expected result unresolved
conflicting	UI copy and server policy describe different expiry rules	Keep both sources and route the conflict to an owner
stale	A prior token report refers to a superseded identity service	Do not treat it as current lifecycle evidence
out_of_scope	Authorization to change another user’s payout account is excluded	Keep the authorization question separate
assumptions	A draft assumes a recovery link can be issued in a test fixture	Name the owner and validation needed to retain the assumption

Separate redacted identity state and token metadata from secret credential values. A login screenshot alone does not establish server-side authentication state or that an earlier credential stopped working.

Consider a design request for passwordless login using an email link, followed by step-up MFA before a payout-account change. The request does not specify link lifetime, single-use behavior, device binding, lock thresholds, or what logout revokes. These remain policy questions; this example does not assert a vulnerability or describe an executed test.

AUT-01 candidate: replay of an email authentication link

Use this candidate only if the supplied requirement says that the link is single-use or otherwise defines replay behavior.

Finding field	Example record
Object and applicability	Email authentication link; applies only when a source defines its recipient, expiry, reuse, and any device-binding rules
Preconditions and stimulus	An approved isolated test identity and a policy-backed issued link; a separate session attempts reuse after the first accepted use. This is a proposed scenario, not an action taken by the Skill.
Expected concern and evidence	If the contract is single-use, determine whether reuse can create another authenticated state or session. Compare server-side state, redacted token metadata, prior-session validity, and audit events; do not infer a bypass from a missing log.
Source and evidence state	The example request supplies no policy, service log, or run record; mark UNASSESSED until those inputs exist
Impact, priority, and owner	Assess impact from the protected account action and product scope; leave priority pending evidence. Route to the authentication or security test owner.
Stop condition	Stop and escalate if the policy conflicts, a production identity or personal credential enters scope, or an unexpected authenticated state is observed.
Validation and close condition	A separately authorized executor may validate the rule in an isolated environment without exposing credential values. Close only when the expected transition, evidence source, owner, and residual risk are reviewable.

The Skill does not log in, call real APIs, read credentials, or execute this candidate. Its result is a proposed validation with explicit conditions, not proof that link replay is possible or prevented.

Keep account recovery and enumeration in scope

Recovery can issue or replace credentials, change sessions, and notify an identity owner. Model which state changes are expected after recovery and whether earlier sessions or tokens remain valid; use only the supplied policy to decide. If the recovery contract is absent, record the transition as missing.

If requirements define different responses for existing and non-existing accounts, compare the documented response and timing evidence. Keep an enumeration concern as a risk candidate until evidence shows disclosure; do not label it a confirmed vulnerability from a conventional expectation alone.

Hand off the lifecycle evidence

For each candidate, pass the source rule, applicability, preconditions, trigger, expected concern, evidence state, impact and priority rationale, owner, stop condition, close condition, and validation method. Keep facts, evidence-backed inferences, candidate recommendations, and Human decisions distinct. Risk acceptance, exceptions, and release judgment stay with an accountable person.

Prepare useful input

Provide the authentication mechanisms in scope, roles, identity states, relevant policy versions, environment boundaries, redacted token/session metadata, audit evidence, and known gaps. Exclude real credential values. If input is incomplete, return a bounded model and name the smallest policy or artifact needed to continue.

Authorization Testing: https://inaodeng.com/en/qaskills/authorization-testing/ examines what an authenticated identity may do.
Session Security Testing: https://inaodeng.com/en/qaskills/session-security-testing/ focuses on session continuity and isolation.
API Security Testing: https://inaodeng.com/en/qaskills/api-security-testing/ examines security controls at API boundaries.

Common mistakes

Treating authentication as a substitute for authorization.
Assuming token lifetime, MFA policy, replay behavior, or lock thresholds without a source.
Testing only the first login and ignoring expiry, revocation, recovery, or prior sessions.
Calling a candidate or static review a confirmed exploit—or claiming security from a missing finding.

Install and invoke

Install the individual Skill:

npx skills add naodeng/awesome-qa-skills --skill authentication-testing

Installation and troubleshooting:

If the tool discovers Agent Skills automatically, describe the task after installation. If it requires explicit invocation, use the syntax supported by that client to select authentication-testing. Provide the policy source and version, authentication mechanisms, identity state, redacted session or token metadata, audit evidence, and environment boundaries. Do not paste real credentials. The Skill prepares static analysis and validation; it does not log in or perform authentication.

For example:

Use authentication-testing to review this email-link login and MFA step-up flow.
Policy source and version: [provide]
Authentication mechanisms and scope: [provide]
Identity state, redacted token/session metadata, and audit evidence: [provide]
Test environment and constraints: [provide; no real credentials or production access]
Return the state transitions, credential lifecycle, and AUT-## candidate findings. Separate confirmed facts, open policy questions, validation suggestions, and Human decisions.

FAQ

Does authentication testing decide whether a user may change a payout account?

No. Authentication establishes identity; authorization and transaction policy determine which actions that identity may perform.

What if email-link expiry or reuse rules are missing?

Keep expected behavior unresolved, mark the related item unassessed, and request the policy owner and smallest source needed before treating it as a test oracle.

No. It does not establish server-side authentication state, token issuance, or whether an earlier credential stopped working. You also need policy, redacted state material, and relevant audit evidence.

References

Read the Authentication Testing Prompt: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/authentication-testing/prompts/authentication-testing.md before invoking the Skill; it defines AUT-## scenarios, evidence boundaries, and the finding contract. The source directory: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/authentication-testing contains the entry point and any supporting assets.

Awesome QA Skills: https://github.com/naodeng/awesome-qa-skills
Authentication Testing details: https://inaodeng.com/en/qaskills/authentication-testing/