Deep nesting fixture

This fixture stresses the IntersectionObserver per-block contract and the section-keying layer with deeply nested heading hierarchy and multi-level lists.

H1 — OAuth foundations

Top-level discussion of OAuth as a delegated authorization framework. OAuth 2.1 consolidates the field.

H2 — Flows

H3 — Authorization Code

H4 — With PKCE

Use PKCE for public clients. The flow:

• client generates a code verifier
  • hashes it to produce the code challenge
    • sends the challenge to the authorization server
      • server returns an authorization code
        • client exchanges code + verifier for an access token

H5 — Loopback redirects

Native apps register a loopback redirect (http://127.0.0.1). The state parameter binds the redirect to the originating session.

H6 — Bonus depth

This H6 exists to test that a host’s CSS reset doesn’t collapse heading hierarchy past H4. The term nonce appears here once.

H4 — Refresh token rotation

The refresh token rotates on each use. The old token is invalidated; the new one is paired with a fresh access token.

H3 — Client Credentials

Server-to-server. No user. scope is the only restriction. mTLS or DPoP binds the token.

H3 — Device Code

For headless devices. User completes the flow on a second device. The verification URI carries a short code.

H2 — Tokens

H3 — JWT family

A JWT is the encoded form. A JWS is a signed JWT. A JWE is an encrypted JWT. An ID token is always a JWS (and optionally a JWE).

H3 — Bearer vs PoP

A bearer token grants access to whoever holds it. DPoP binds the token to a key the holder must prove possession of.

H2 — Endpoints

H3 — Discovery

.well-known/oauth-authorization-server lists:

• token endpoint
• authorization endpoint
• introspection endpoint
  • revocation endpoint
• registration endpoint
• PAR endpoint (Pushed Authorization Requests)
  • JWKS URI
  • userinfo endpoint
    • resource server indicator

H3 — Token endpoint

POST grant_type=authorization_code with the PKCE verifier. Server returns an access token, an optional refresh token, and (for OIDC) an ID token.

H1 — Hardening

H2 — Threats

Re-using OAuth across the section to ensure cross-section term repetition works under deep nesting:

• OAuth 2.1 disallows the implicit flow
  • mandates PKCE for all clients
    • even confidential ones
      • this is the load-bearing change
        • relative to OAuth 2.0
• state parameter is mandatory
• nonce is mandatory for OIDC ID tokens

H2 — Mitigations

• mTLS for client authentication
• DPoP for sender-constrained tokens
• PAR for redirect-URI integrity
• Short-lived access tokens with rotated refresh tokens

H1 — Closing prose

OAuth’s complexity is a tax. PKCE, DPoP, PAR, and mTLS each address a specific historical failure. Use OAuth 2.1 defaults and accept the boilerplate. The terms OAuth, OAuth 2.1, PKCE, scope, refresh token, access token, ID token, JWT, JWS, JWE, nonce, state, client, resource server, authorization server, bearer, DPoP, mTLS, PAR, and introspection all appear at least once in this fixture and should each get at least one mark in the post-hydration DOM.