OAuth 2.0 and OpenID Connect Flow Security Review Prompt

This prompt is designed for security engineers and architects who need to review OAuth 2.0 and OpenID Connect (OIDC) flow designs before implementation. It accepts a flow description, grant type, and architectural context, then produces a structured threat analysis covering redirect validation, token leakage, scope over-provisioning, and RFC compliance gaps. Use this prompt during design review gates, security architecture assessments, or when onboarding a new identity provider integration.

The prompt assumes the reviewer has access to a flow diagram, client configuration details, and the intended authorization server behavior. It is most effective when the [FLOW_DESCRIPTION] includes the specific endpoints, client types (confidential vs. public), and token handling mechanisms in play. The output is a threat list organized by attack surface—redirect URI manipulation, CSRF state parameter weaknesses, PKCE bypass, token storage risks, and scope mismatch—with each threat mapped to the relevant RFC section (e.g., RFC 6749, RFC 7636, RFC 6819) for traceability.

This prompt is not a substitute for a full penetration test or a formal threat model; it is a design-time review tool that surfaces protocol-level risks early. Do not use it to review live production traffic, to generate compliance attestations, or as the sole security gate before deployment. For high-risk flows involving financial transactions, healthcare data, or cross-tenant access, pair the output with a manual review by a security architect and a runtime token-inspection test plan.

This prompt template is designed to be copied directly into your AI harness or prompt management system. It uses square-bracket placeholders for all variable inputs, allowing you to adapt it to different grant types, system designs, and risk profiles without modifying the core instruction structure. The template instructs the model to act as a security architect and produce a structured threat analysis, not a generic security opinion.

textCopy
You are a security architect specializing in authentication and authorization protocols. Your task is to perform a structured security review of an OAuth 2.0 or OpenID Connect flow design.

## INPUT
[FLOW_DESIGN_DOCUMENT]

## REVIEW PARAMETERS
- Grant Type: [GRANT_TYPE]
- Client Type: [CLIENT_TYPE]
- Token Binding Method: [TOKEN_BINDING]
- Identity Provider: [IDP]
- Risk Level: [RISK_LEVEL]

## CONSTRAINTS
- Base your analysis strictly on the provided design document and the RFCs for OAuth 2.0 (RFC 6749), OAuth 2.1 (draft), and OpenID Connect (OIDC Core 1.0).
- Do not invent threats for components not described in the input.
- If the design document omits a critical detail (e.g., redirect URI validation, PKCE, state parameter), flag it as a finding with "INSUFFICIENT INFORMATION" severity.
- For each finding, cite the specific RFC section or OWASP ASVS requirement that applies.

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "review_summary": {
    "grant_type": "string",
    "overall_risk": "LOW|MEDIUM|HIGH|CRITICAL",
    "findings_count": "integer",
    "critical_findings_count": "integer"
  },
  "findings": [
    {
      "id": "F-001",
      "category": "REDIRECT_VALIDATION|TOKEN_HANDLING|SCOPE_PROVISIONING|SESSION_MANAGEMENT|CSRF|CLIENT_AUTH|DISCOVERY|OTHER",
      "severity": "CRITICAL|HIGH|MEDIUM|LOW|INSUFFICIENT_INFORMATION",
      "title": "string",
      "description": "string",
      "rfc_reference": "string",
      "owasp_asvs_reference": "string",
      "remediation": "string"
    }
  ],
  "flow_completeness": {
    "missing_elements": ["string"],
    "non_compliant_elements": ["string"]
  }
}

## INSTRUCTIONS
1. Parse the provided flow design document and identify the authorization flow steps.
2. For the specified grant type, enumerate the mandatory security controls from the relevant RFCs.
3. Compare the design against each mandatory control and identify gaps.
4. For each gap, produce a finding with a unique ID, category, severity, and remediation.
5. Assess overall risk based on the highest-severity finding and the number of critical findings.
6. Populate the flow_completeness object with any missing or non-compliant elements.

To adapt this template, replace each placeholder with concrete values from your review context. The [FLOW_DESIGN_DOCUMENT] should contain the full text of the architecture document, sequence diagram description, or configuration specification you are reviewing. The [GRANT_TYPE] must be one of authorization_code, client_credentials, refresh_token, or device_code—avoid reviewing the deprecated implicit grant without an explicit decision to do so. The [RISK_LEVEL] parameter should reflect your organization's data classification for the resources protected by this flow, which influences the severity calibration in the model's output.

Before deploying this prompt in a production review pipeline, validate the output against a known set of golden test cases. At minimum, test with a deliberately broken flow that omits PKCE, a flow missing redirect URI validation, and a compliant flow to ensure the model correctly distinguishes between secure and insecure designs. If the review is for a high-risk system, route all CRITICAL findings for human security architect review before accepting the output as final.

This prompt is designed to operate as a security review microservice within a larger architecture review pipeline. It expects a structured input payload containing the grant type, redirect URIs, client configuration, token endpoint details, and scope definitions. The prompt should be called programmatically via an API (OpenAI, Anthropic, or a self-hosted model) with the response parsed into a structured JSON output for downstream processing. Because the output contains security findings that may influence architectural decisions, the harness must enforce strict output validation before any findings are accepted or displayed.

Integration pattern: Wrap the prompt call in a function that (1) assembles the input from your design document or configuration file, (2) calls the model with response_format set to json_object (or equivalent structured output mode), (3) validates the returned JSON against a defined schema, and (4) routes findings to the appropriate review queue. For high-risk flows (authorization code with PKCE, client credentials for service accounts), implement a human review gate: if the model flags a severity: critical finding or identifies a violation of RFC 6749/7636/8252, the output must be surfaced in a review interface (Jira, Linear, GitHub Issue) with the raw model response and source evidence attached. Never auto-apply security findings to production configurations without human sign-off.

Validation and retry logic: Define a JSON schema for the expected output—fields like grant_type, threats[], misconfigurations[], rfc_compliance_gaps[], and remediation_steps[]. After each model call, validate the response against this schema. If validation fails, implement a single retry with the error message appended to the prompt as [VALIDATION_ERROR]. If the retry also fails, log the raw response, flag the review as incomplete, and escalate to a human reviewer. For model choice, prefer models with strong structured output support (GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to maximize consistency. Log every call with the input hash, model version, latency, token usage, and validation status for auditability and cost tracking.

What to avoid: Do not use this prompt as a real-time gate in an authentication flow—it is a design-time review tool, not a runtime policy engine. Do not feed live tokens, secrets, or production client credentials into the prompt; use redacted or synthetic representations. If the prompt identifies a finding that contradicts your existing security controls, treat it as a hypothesis to investigate, not a ground-truth verdict. Always cross-reference model findings against your organization's specific OAuth/OIDC implementation, identity provider documentation, and threat model before taking action.