OpenID Connect Authentication Profile Design

    1

    Designs OpenID Connect profiles: ID token schemas, Discovery endpoints, nonce replay defense, and backchannel logout.

    $5

    Secure checkout via Stripe

    Money-back guarantee

    Converts to your local currency at checkout

    Security scanned

    Works with the AI Agents you already use

    Claude CodeClaude CodeCursorCursorCodex CLICodex CLIDeepSeekDeepSeekMuseMuse+22 more

    OpenID Connect Authentication Profile Design

    Example session with this skill installed

    Design OpenID Connect (OIDC) identity authentication profile and session lifecycle contract for our Retail Banking Customer Portal.

    • Subject: retail-banking-portal v3.0 (run-id: banking-portal-oidc-001) authenticating 3.8 million consumer banking customers.
    • Deciders: Lead Application Security Architect (David O'Reilly) and Head of Digital Channels (Elena Rostova).
    • Scope: OpenID Connect Core 1.0; Authorization Code Flow with PKCE (RFC 7636); peak 4,200 authentications/sec; p99 latency <= 5.0 ms.
    • Tension: Mobile squad proposed legacy Implicit Flow without PKCE or nonce verification; David O'Reilly and Elena Rostova strictly reject Implicit Flow and missing nonces, citing incident OIDC-4929 where an intercepted ID token was replayed to hijack customer accounts. They mandate Authorization Code Flow with S256 PKCE, cryptographic nonce binding in ID tokens, OpenID Discovery metadata (/.well-known/openid-configuration), UserInfo endpoint data minimization, and OIDC Backchannel Logout (RFC 8693).

    Write the OIDC authentication profile contract specification under docs/.

    • Read your context and instructions
    • Compiled the openid connect authentication

    Wrote docs/architecture/tasks/banking-portal-oidc-001/oidc-design/oidc-profile-contract.md. Complete OpenID Connect authentication profile specification establishing Authorization Code Flow with PKCE, cryptographic nonce binding, ID Token validation, and Backchannel Logout.

    ---
    skill: oidc-design
    ---
    
    # OIDC Authentication Profile Contract: Retail Banking Portal [OIDC-BANK-001]
    
    ## Summary
    
    This specification establishes the OpenID Connect (OIDC) authentication profile, ID Token schema, cryptographic validation sequence, and session termination contract for `retail-banking-portal v3.0` under run ID `banking-portal-oidc-001`, authenticating 3.8 million active consumer banking accounts across web and mobile channels. It decisively eliminates the token interception and session hijacking vulnerabilities demonstrated in incident OIDC-4929 (where an unconstrained Implicit Flow token without nonce verification was intercepted via browser history and replayed). The contract enforces the OIDC Authorization Code Flow with Proof Key for Code Exchange (PKCE S256), cryptographic `nonce` binding in ID Tokens, OpenID Provider Discovery metadata (`/.well-known/openid-configuration`), UserInfo endpoint data minimization, and OIDC Backchannel Logout (RFC 8693) ensuring simultaneous session revocation across distributed clients.
    
    ## Detailed Description
    
    Using the legacy OIDC Implicit Flow on public mobile applications or single-page web applications (SPAs) returns identity tokens directly in URL hash fragments, exposing sensitive credentials to browser history, referrer headers, and man-in-the-browser attacks. Modern authentication requires Authorization Code exchange with cryptographically generated code verifiers and single-use nonces.
    
    

    Consumer Web / Mobile App (3.8M Users, 4,200 auth/sec)
    │
    ▼ (Step 1: Auth Request: response_type=code, code_challenge=S256(...), nonce=n-8a2f...)
    [ Central Identity Provider (IdP): OpenID Discovery ]
    ├── 1. Authenticates User with FIDO2 / Biometrics
    └── 2. Returns Authorization Code via Redirect URI (No Tokens in Fragment)
    │
    ▼ (Step 2: Direct Backchannel POST: Code + code_verifier)
    [ Banking Portal Backend: Token Endpoint /oauth/v2/token ]
    ├── 1. Verifies PKCE: SHA256(code_verifier) == code_challenge
    ├── 2. Issues ID Token: Injects nonce: "n-8a2f...", exp, sub, auth_time
    └── 3. Issues Access Token (15m TTL) & Refresh Token
    │
    ▼ (Step 3: Client Validation Pipeline)
    [ Client Gatekeeper: Nonce & Signature Verification ]
    ├── Asserts: Token Nonce == Local Ephemeral Nonce
    └── Asserts: Issuer, Audience, Expiration, and Alg == "ES256"

    
    ### Criteria and weights
    
    | Criterion | Why it matters here | Weight | Source of the weight |
    |---|---|---|---|
    | Token Interception & Replay Immunity (PKCE + Nonce) | Intercepted authorization codes or ID tokens must be cryptographically unusable (OIDC-4929). | 0.40 | David O'Reilly (CISO SecOps) |
    | Front-Channel Data Privacy & Token Hygiene | Tokens must never appear in HTTP GET query parameters, server access logs, or browser histories. | 0.30 | Elena Rostova (Head of Digital Channels) |
    | Unified Multi-Device Session Invalidation | User logout or account suspension must terminate active sessions across web and mobile concurrently. | 0.20 | Banking Regulatory Compliance |
    | Authentication Latency Budget (p99 <= 5.0 ms) | Token verification and UserInfo checks must not degrade high-throughput interactive logins. | 0.10 | Retail Customer SLA |
    
    
    ### Comparison
    
    | OIDC Authentication Flow | Grant Type | Token Delivery Seam | Replay Defense | Evaluation |
    |---|---|---|---|---|
    | Option A: Legacy Implicit Flow | `response_type=id_token` | Front-channel URL fragment | Optional nonce | Rejected: Allowed OIDC-4929 session hijacking; leaks tokens in logs. |
    | Option B: Pure OAuth 2.0 Auth Code | `response_type=code` | Backchannel `/token` POST | None (No ID Token) | Rejected: Lacks standardized identity assertions, `auth_time`, and UserInfo. |
    | Option C: OIDC Auth Code + PKCE (Chosen) | `code` with S256 PKCE | Secure Backchannel POST | Mandatory cryptographic nonce | Selected: Full OAuth 2.0/OIDC security, 100% immune to interception. |
    
    
    ### Result
    
    Option C is selected. Authorization Code Flow with PKCE S256 and cryptographic nonce binding guarantees zero token leakage and complete replay immunity.
    
    ---
    
    ### Required Mechanisms
    
    #### 1. OpenID Discovery Configuration Metadata [MC-DC-01]
    - Hosted at `https://auth.bank.internal/.well-known/openid-configuration`:
      ```json
    
    ```json
      {
        "issuer": "https://auth.bank.internal",
        "authorization_endpoint": "https://auth.bank.internal/as/authorization.oauth2",
        "token_endpoint": "https://auth.bank.internal/as/token.oauth2",
        "userinfo_endpoint": "https://auth.bank.internal/idp/userinfo.openid",
        "jwks_uri": "https://auth.bank.internal/pf/JWKS",
        "end_session_endpoint": "https://auth.bank.internal/idp/endSession.openid",
        "response_types_supported": ["code"],
        "subject_types_supported": ["public", "pairwise"],
        "id_token_signing_alg_values_supported": ["ES256"],
        "code_challenge_methods_supported": ["S256"],
        "backchannel_logout_supported": true
      }
    
    
    - **Prohibition**: `response_types_supported` strictly omits `token` and `id_token` standalone modes (Implicit Flow disabled).
    
    #### 2. Authorization Code Flow with PKCE & Nonce Contract [MC-PK-01]
    - **Client Request Parameters**:
      - `response_type=code`
      - `client_id=banking-retail-web`
      - `scope=openid profile email accounts:read`
      - `redirect_uri=https://retail.bank.internal/auth/callback`
      - `code_challenge={BASE64URL(SHA256(code_verifier))}`
      - `code_challenge_method=S256`
      - `nonce={CSPRNG_HEX_STRING_32BYTES}`
    - **Backchannel Exchange**:
      - Exchanged directly via HTTP POST to `/token.oauth2` using TLS 1.3. Plaintext `code_challenge_method: plain` is rejected with HTTP 400.
    
    #### 3. ID Token Claims Schema & Verification Sequence [MC-ID-01]
    - **ID Token Payload Schema**:
      ```json
      {
        "iss": "https://auth.bank.internal",
        "sub": "c4b1e892-9921-4f1a-8812-7f3a8b9c0d1e",
        "aud": "banking-retail-web",
        "exp": 1757942100,
        "iat": 1757941200,
        "auth_time": 1757941195,
        "nonce": "n-7f8e3a2d4c1b9a0e",
        "acr": "urn:bank:acr:fido2:mfa",
        "amr": ["fido2", "pin"]
      }
    
    • Client Verification Algorithm:
      1. Header check: asserts alg == "ES256" and resolves kid against cached JWKS.
      2. Cryptographic signature check over header and payload.
      3. Claims check: asserts iss matches discovery issuer, aud matches client ID, now < exp, and nonce strictly matches the local ephemeral string saved in client session storage prior to authorization request.
    4. OIDC Backchannel Logout (RFC 8693) [MC-BL-01]
    • When a user logs out or customer support initiates a security lock:
      1. IdP sends direct server-to-server POST to https://retail.bank.internal/logout/backchannel.
      2. Payload: Signed Logout Token (typ: "logout+jwt") containing sub and sid (session ID).
      3. Portal backend revokes the local customer session and deletes cached authorization tokens in < 200 ms.

    Invariants and Contracts

    Implicit Flow Prohibition Invariant [INV-OIDC-01]
      Production client applications are strictly forbidden from using OIDC Implicit Flow.
      All authentication requests must use `response_type=code` with PKCE S256.
    
    Mandatory Nonce Binding Mandate [INV-OIDC-02]
      Every authentication request must generate a cryptographically random nonce.
      Client applications must verify that the `nonce` claim in the returned ID Token exactly matches
      the local request nonce. Tokens with missing or mismatched nonces are rejected.
    
    Symmetric Algorithm Disallowance [INV-OIDC-03]
      ID Tokens must be signed with asymmetric algorithms (`ES256`).
      Symmetric HMAC signing (`HS256`) or `alg: "none"` are prohibited by OpenID Provider policy.
    

    Explicit Unknowns

    • Network timeout latency during simultaneous Backchannel Logout dispatches across 35 downstream internal portals (G-1).
    • Safari Intelligent Tracking Prevention (ITP) impact on session cookie persistence during third-party IdP redirects (G-2).

    Traceability

    ClaimClassificationSourceFreshness
    3.8 million consumer banking accountsprovidedCustomer base intakeCurrent
    Peak 4,200 authentications/secprovidedTraffic profile intakeCurrent
    Incident OIDC-4929 token replay breachprovidedPost-mortem incident recordHistorical
    Latency budget p99 <= 5.0 msprovidedPerformance SLACurrent
    Authorization Code + PKCE S256 mandatedecidedDavid O'Reilly (CISO SecOps)2026-09-15
    OIDC Backchannel Logout (RFC 8693)decidedElena Rostova (Head of Channels)2026-09-15

    Verification

    No validator was supplied, so no command was run.

    Reviewer self-check against OIDC architecture standards:

    • Flow Safety: PASS. Prohibits Implicit Flow; enforces Auth Code with PKCE S256 and nonces.
    • Token Verification: PASS. Strict validation of iss, sub, aud, exp, and nonce.
    • Session Lifecycle: PASS. RFC 8693 Backchannel Logout guarantees concurrent cross-device termination.
    • Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

    Open Decisions

    • DEC-OIDC-01: David O'Reilly to determine whether Pairwise Pseudonymous Identifiers (PPID) should be mandated for third-party open-banking aggregators to prevent cross-merchant tracking (Owner: David O'Reilly).

    Next steps

    1. David O'Reilly configures central IdP OpenID Discovery metadata and disables Implicit Flow globally.
    2. Platform team implements PKCE S256 and nonce generation in web/mobile authentication SDKs.
    3. Conduct staging penetration test attempting to exchange authorization codes with invalid PKCE verifiers.

    Connects securely to your tools. The creator never sees your data.

    About this skill

    What it does

    This skill maps an accepted OpenID Connect use into exact authentication request, ID-token, claims, UserInfo, subject, session and logout contracts. It composes selected OAuth transport with identity/session authority without redesigning either.

    Use it when

    Use when selected OPs and relying parties need a bounded OIDC authentication profile and validation/lifecycle semantics.

    For example: “We moved to SSO. A user changed their surname and email, and now they have two accounts with different permissions. Also, logging out of the identity provider doesn't log them out of our app.”

    What you get

    • OIDC Spec

    Written as Markdown to <your output folder>/architecture/tasks/<run-id>/oidc-design/.

    What it will not do

    Do not use for selecting an IdP/OIDC, OAuth delegated-authorization design, enterprise IAM/federation/session architecture, JWT/key profiles, API authorization, social-login implementation or provider configuration.

    How it works

    1. Check you need identity, not access.
    2. Decide what the ID token establishes and for how long.
    3. Validate every part of the ID token, and say which.
    4. Map claims to a local subject deliberately.
    5. Define session lifetime, re-authentication and single logout.
    6. Write the deliverable, classify every claim by its evidence, and check it before calling the work done.

    What's in the package

    Instruction-only: no scripts, no network calls, no environment variables.

    • LICENSE.txt
    • SKILL.md
    • agents/openai.yaml
    • assets/output-template-task.md
    • references/domain-rules.md
    • references/operating-rules.md
    • references/output-contract.md

    Find more skills like this on the Claude Skills Marketplace, the Codex Skills Marketplace and the Gemini Skills Marketplace, or browse Claude Skills for Security.

    Do not use for selecting an IdP/OIDC, OAuth delegated-authorization design, enterprise IAM/federation/session architecture, JWT/key profiles, API authorization, social-login implementation or provider configuration.

    How to use

    1. 1

      Connect your agent to the Agensi MCP

      Copy the prompt and paste it into Claude, ChatGPT, Cursor or any agent that supports MCP. It sets up the connection for you. Manual setup

    2. 2

      Sign in to Agensi

      Your agent shows a sign-in link. Sign in and click Allow.

    3. 3

      Ask for what you need

      Your agent loads this skill and uses it on your task. It always asks before buying a skill.

    Reviews

    No reviews yet

    Be one of the first to try it. Every listed skill goes through the trust checks below.

    Security scanned

    Checked by our 8-point scan before listing

    Fresh listing

    Recently published to Agensi

    Money-back guarantee

    Doesn't do what its page promises? You get your money back.

    Trust & safety

    Security scan

    Security scan passed 1 month ago

    Permissions

    Read Files
    Write Files
    Listed1 month ago

    What's inside

    Frequently Asked Questions

    No. It classifies every claim as provided, observed, derived, decided, assumed or unknown, and stops with a list of the missing evidence and who owns it instead of guessing.

    No. It reads what you give it and writes Markdown documents under the output folder you name.

    Any agent that supports SKILL.md skills, including Claude Code, Codex CLI, Cursor and Gemini CLI. It has no scripts and makes no network calls.

    Unzip it into your agent's skills folder, for example: unzip oidc-design.zip -d ~/.claude/skills/

    New in Security