Quality report

Gate result

PASS

Document type: technical_blog
Reader language: ko-KR
Citation mode: hidden
Source pack: 48 entries
Required H2 intents: 8/8, in contract order
Deterministic lint: 100.0/100
ClariDoc word count: 9,043
Blockers: 0
Errors: 0
Warnings: 0

No mock-provider score is used as evidence of prose or factual quality.

Evidence collection

All four pattern tips were inspected independently and read-only:

Pattern	Git tip
AP1	`bb8fd9333d7da1c6424d6e0b039fc1c80c2cf0ca`
AP2	`d019846f8725bdb0badde33043b020dc252e32ff`
AP3	`934c5da5d6edc2429dfb558b773656e46f21d677`
AP4	`f4aea65dc6255eae07b20ebbe21e02fb6115e563`

The canonical develop corpus was merged with branch-specific implementation, configuration, test-contract, decision-rationale, and worked-flow evidence. The expanded evidence covers browser entry, authorization callback, token/session storage, controller and framework transformations, downstream requests, exact reader JSON fields, failure statuses, and implementation gaps.

The common comparison described AP2 as a short or one-time handoff, but the current controller returns the raw Keycloak access token on repeatable authenticated GET requests and has no nonce consumption or deletion. The article therefore uses the implementation-backed term access-only handoff.

Reference-document calibration

The requested comparison document was inspected for its authoring pattern. Its important technique is a concrete initial HTTP input followed through actual classes and methods, intermediate models, next-hop input, and observable final output. The revised Keycloak article applies the same technique separately to:

AP1 login callback and browser Bearer /api/me;
AP2 login session, /token/boundary, /token/access, and direct API call;
AP3 login, /bff/api/me, CSRF issuance, and preference POST;
AP4 login redirect, Nginx auth subrequest, upstream rewrite, and identity JSON.

Independent reviews and revisions

AP1 and AP2 technical review

Initial result: NEEDS REVISION

Material findings:

the general Authorization Code introduction implied that every pattern used a code_challenge, contradicting AP2's unverified PKCE boundary;
the AP1 browser E2E was said to assert username, while its live assertion is UI status plus decoded audience;
AP2's AP2_SESSION transaction role before callback was missing;
CORS wording could be mistaken for network-level access control;
dynamic audience examples looked exact;
AP1's local wildcard redirect registration and the diagnostic-server negative test shape were not explicit.

All findings were revised. Targeted re-review result: PASS, with no remaining blocker, error, or warning.

AP3 and AP4 technical review

Initial result: NEEDS REVISION

Material findings:

AP3 incorrectly placed the ID token in OAuth2AuthorizedClientService; the corrected text separates access/refresh token storage from the ID-token-derived OIDC principal in SecurityContext;
AP4 was initially grouped with server-side session cookies and was assigned persistent refresh-token custody; the corrected text describes the configured minimal client-side cookie, absence of a shared server store, and the unverified refresh lifecycle;
the AP3 handler was named updatePreferences instead of the actual updatePreference;
the cross-site test was described beyond its exact assertion, which only checks that AP3_SESSION is absent from the request.

All findings were revised. Targeted re-review result: PASS, with no adjacent regression found.

Reader, logic, evidence, and procedure review

Initial result: PASS WITH ONE WARNING

The only warning was that “oauth2-proxy manages the Keycloak session” could confuse the IdP SSO session with AP4's proxy session. The sentence now says that oauth2-proxy owns OIDC code exchange and AP4_SESSION verification while Nginx owns upstream request and identity-header construction.

The reviewer confirmed that:

all four patterns contain a complete input → transformation → next hop → output trace;
test-defined contracts remain separate from fresh execution claims;
hidden source metadata does not leak into reader prose;
destructive volume reset is surrounded by prerequisites, stop conditions, backup, and recovery guidance;
each choice includes context, rationale, alternative, accepted cost, guardrail, and evidence boundary.

Validation performed

Brief and 48-entry SourcePack runtime validation: PASS
Deterministic preliminary outline generation: PASS
Refined outline contract: PASS, 8 required intents in order
Every refined-outline evidence ID resolves in the SourcePack: PASS
Reader/provenance separation and hidden-citation leakage lint: PASS
Final deterministic document lint: PASS, 100.0/100, 0 issues
ClariDoc unit and integration suite: PASS, 41 tests
Target repository after inspection: clean develop
Four remote pattern refs re-resolved to the reviewed Git tips: PASS
Earlier read-only manifest/ref audit: 39 declared feature refs exist and are reachable from their declared target branches

Validation deliberately not performed

The pattern verification scripts rebuild their stacks after deleting Docker volumes. They were not run during this documentation task. The article therefore describes committed acceptance contracts rather than claiming a fresh runtime PASS.

The repository-provided branch audit still depends on a branch-note inventory outside the available local path. The separate read-only Git reachability check does not substitute for those missing note files.

The ClariDoc scripts/verify.sh workflow was not run because this worktree already contains extensive user changes and that workflow removes or rebuilds distribution and generated demo artifacts. The non-destructive 41-test suite, contract validation, outline validation, and final lint were run instead.

Remaining evidence boundaries

AP1's E2E does not directly assert the token-request code_verifier, automatic silent renewal, exact IdP cookie flags, CORS preflight, invalid signature, or expired-token negative cases. Its local realm uses wildcard redirects.
AP2 does not implement one-time consumption and does not verify expiry-driven refresh, logout, durable session/token storage, or handoff replay rejection.
AP3 does not implement a shared session/token store, token-at-rest encryption, coordinated logout, downstream failure mapping, or user-scoped persistence for the preference example.
AP4's minimal cookie does not establish persistent refresh-token custody. Role propagation, generalized endpoint enforcement, state-changing-request CSRF, multi-replica cookie-secret lifecycle, and internal secret rotation remain outside the verified contract.
The Google harness uses a controllable mock identity provider. Real external accounts and public-HTTPS acceptance remain separate.
Performance, load, high availability, recovery, and long-duration session behavior are outside the verified scope.

7.1 KiB Raw Blame History