Session and Token Lifecycle Exploration Charter Prompt

This prompt is designed for security-minded testers and QA engineers who need to move beyond scripted authentication test cases and into structured, time-boxed exploratory investigation. The core job-to-be-done is generating a mission-driven charter that targets the complex, often vulnerable, lifecycle of authentication sessions and tokens. Ideal users are those who have access to system architecture documentation, token lifecycle specifications, or observed session behavior and need to convert that context into a focused test plan. The output is not a generic list of test cases; it is a specific investigation mission with clear targets, security oracle expectations, and time-boxing guidance.

You should use this prompt when you need to probe specific high-risk areas: concurrent session handling, token reuse after revocation, forced logout propagation, expiry boundary conditions, and refresh token rotation. The prompt requires substantive input context to be effective. Placeholders like [SYSTEM_ARCHITECTURE_CONTEXT] and [TOKEN_LIFECYCLE_SPECIFICATION] are not optional; they are the raw material the model uses to generate a relevant charter. Without them, the output will be generic and miss the specific implementation details that make an exploratory charter valuable. The prompt is designed to produce a charter with an explicit mission statement, investigation targets, and security oracle expectations—a clear definition of what correct and incorrect behavior looks like for a given security control.

Do not use this prompt for general authentication test case generation or for systems where session management is entirely delegated to a third-party identity provider with no custom token handling logic. For those scenarios, a standard test case generation prompt or an integration-specific charter prompt is more appropriate. After generating a charter, your next step is to execute the time-boxed session, using the charter's mission and oracles to guide your investigation and capture findings in a structured note-taking scaffold. The charter is a starting point for human-driven exploration, not a replacement for it.

This prompt template generates a structured exploratory test charter for investigating session and token lifecycle management. It is designed for QA engineers and security-minded testers who need to probe authentication boundaries, token expiry, concurrent sessions, and revocation propagation. The charter output includes a clear mission, investigation targets, oracle heuristics, and time-boxing guidance. Before executing, replace all square-bracket placeholders with your specific application context, including the authentication mechanism, token types, and any known risk areas.

textCopy
You are an expert exploratory tester specializing in authentication and session security.

Generate a time-boxed exploratory test charter for investigating session and token lifecycle behavior in the following system:

[APPLICATION_CONTEXT]
- Application name: [APP_NAME]
- Authentication mechanism: [AUTH_MECHANISM, e.g., OAuth2, SAML, JWT, session cookies]
- Token types in use: [TOKEN_TYPES, e.g., access token, refresh token, ID token, CSRF token]
- Session storage: [SESSION_STORAGE, e.g., server-side, client-side cookie, local storage]
- Known risk areas: [KNOWN_RISKS, e.g., recent logout bug, concurrent session complaints, token refresh failures]

[CONSTRAINTS]
- Time box: [SESSION_DURATION, e.g., 90 minutes]
- Test environment: [ENVIRONMENT_DETAILS, e.g., staging, user acceptance, production-readiness]
- Focus areas: [FOCUS_AREAS, e.g., forced logout propagation, token reuse after revocation, expiry boundary behavior, concurrent session limits]
- Out of scope: [OUT_OF_SCOPE, e.g., brute-force protection, password policy, social login flows]

[OUTPUT_SCHEMA]
Produce a charter with the following sections:
1. **Mission**: A one-sentence objective describing what will be investigated.
2. **Time Box**: The allocated session duration.
3. **Investigation Targets**: A bulleted list of specific behaviors, boundaries, and scenarios to probe. Include at least 5 targets covering:
   - Token expiry boundary conditions (e.g., exactly at expiry, one second after, clock skew scenarios)
   - Token reuse after explicit revocation (logout, password change, admin-forced session termination)
   - Concurrent session behavior (multiple tabs, multiple devices, same user)
   - Forced logout propagation (how quickly termination takes effect across sessions)
   - Refresh token rotation and replay detection
4. **Oracle Heuristics**: For each investigation target, describe what correct behavior should look like. Include specific HTTP status codes, error messages, or redirect behaviors expected.
5. **Test Data Requirements**: Any accounts, tokens, or configurations needed before starting.
6. **Note-Taking Scaffold**: A minimal table with columns for Observation, Expected vs Actual, and Follow-Up Needed.
7. **Risk Assessment**: A low/medium/high rating for the likelihood of finding a defect in each target area.

[EXAMPLES]
Example investigation target: "Access a protected resource with an access token exactly at its expiry timestamp. Verify whether a 401 is returned or a grace period is applied."
Example oracle: "Expected: HTTP 401 with WWW-Authenticate header. Token must not be accepted. No grace period unless documented."

After pasting this prompt, verify that all placeholders are replaced with concrete values. Vague inputs like 'standard OAuth' will produce generic charters that miss application-specific risks. If your application uses multiple token types or session stores, list them all explicitly. The output charter should be specific enough that a tester unfamiliar with the system can execute it within the time box without additional clarification. For high-risk financial or healthcare systems, add a [RISK_LEVEL] placeholder set to 'high' and require a security reviewer to approve the charter before execution.

This prompt is designed to be called programmatically as part of a QA toolchain, not as a one-off chat interaction. The typical integration point is a test planning service that receives a feature context payload (authentication flow documentation, token architecture notes, session management design) and returns a structured exploration charter. Because the output drives security-sensitive testing, the harness must validate the charter's completeness before a tester begins the session. The prompt expects [AUTH_FLOW_DOCS], [TOKEN_ARCHITECTURE_NOTES], and [RISK_AREAS] as inputs. These should be assembled from your test management system, architecture decision records, or security review documents. Do not pass raw JWT tokens, production session cookies, or live credentials into the prompt context; summarize the mechanics instead.

Wire the prompt through an API call with explicit validation steps. After receiving the model response, parse the JSON output and validate that required fields are present: charter_mission, investigation_targets (minimum three items), oracle_heuristics, and session_timebox. If the model returns malformed JSON, implement a retry with the error message appended to the next request as a correction hint. For high-risk authentication testing, add a human review checkpoint before the charter is assigned to a tester: a QA lead should confirm that the charter does not inadvertently suggest destructive actions (e.g., revoking all production tokens) and that oracle heuristics align with your security policy. Log every charter generation attempt—including inputs, raw output, validation errors, retries, and reviewer decisions—so that charter quality trends can be audited over time. Model choice matters here: use a model with strong instruction-following for structured JSON output (GPT-4o, Claude 3.5 Sonnet) rather than a smaller or faster model that may drop fields or hallucinate test scenarios.

Do not treat this prompt as a fire-and-forget generator. The charter it produces is a starting point for a human exploratory tester, not an automated test script. After the session, feed the tester's notes back into the Exploratory Session Debrief and Coverage Gap Prompt to assess what was found and what remains untested. Avoid wiring this prompt directly into an automated security scanner; the output describes what to investigate, not how to execute specific attacks. For token lifecycle testing specifically, ensure your harness enforces that any generated charter referencing token replay, forced logout propagation, or concurrent session manipulation is reviewed by someone with AppSec context before execution begins.