fix(proxy): revoke all cached tokens during backchannel logout

[zerox80]

Description

When a session receives a refreshed access token, its cache lookup currently replaces the previous token's hash. Backchannel logout can therefore leave older cached tokens usable. Deleting cached claims also allows a locally verified JWT to authenticate again when PROXY_OIDC_SKIP_USER_INFO is enabled.

Register each accepted token separately and retain revocations independently of cached claims. Logout invalidates every tracked token matching the requested subject or session. Authentication checks revocation before using a token and after registering new claims, so a concurrent claims write cannot restore a logged-out token. Notification failures no longer prevent invalidation.

Preserve per-record expiry across memory, Redis, and NATS using a dedicated OIDC cache namespace. Import unexpired legacy claims on startup and clean up expired records. Empty legacy NATS buckets require no migration. Physically purge NATS delete markers within the configured table and through the observed revision, preserving concurrent writes. This prevents a bucket-wide TTL from dropping revocations before their tokens expire while keeping expired state from accumulating.

Commit sequence

1. Support per-token logout records. Introduce compatible lookup and revocation keys, support multiple tokens per session, and add the matching unit tests.
2. Preserve OIDC cache expiry across storage backends. Add the cache wrapper, legacy migration, startup wiring, cleanup, and memory/Redis/NATS tests.
3. Revoke every tracked token on backchannel logout. Connect authentication and logout to the new records, with HTTP and concurrency regression tests.
4. Document logout persistence and cache upgrades. Explain operational behavior and add the changelog entry.
5. Accept empty NATS caches during migration. Handle new, expired, and marker-only buckets without hiding connection failures; include native NATS regression tests.
6. Remove NATS delete markers. Add scoped cleanup bounded by the observed revision, using the cache authentication and TLS settings, with storage and concurrency regression tests.

Tests are included with the behavior they validate. The first four commits split the original patch; the final two address the NATS startup and cleanup review findings.

Related Issue

No issue linked.

Motivation and Context

Backchannel logout must invalidate all tokens already accepted for the affected session, including tokens issued before a refresh and tokens verified without a userinfo request.

Revocations are retained until the verified token expiry. Tokens without a verified expiry, including migrated legacy entries, retain logout state indefinitely. All proxy instances must use the updated code and the same persistent store to share revocations; memory-backed state is lost on restart. The proxy documentation explains the cache namespace and upgrade behavior.

How Has This Been Tested?

Test environment: Ubuntu under WSL, Go 1.25.9, vendored dependencies, Redis 7.0.15, and the vendored NATS server.

• Six HTTP regression cases fail on the unmodified base with HTTP 200 instead of HTTP 401, and pass with the fix. They cover subject-only, session-only, and combined logout, with userinfo enabled and disabled.
• Additional tests cover concurrent claims writes, storage failures, repeated logout, unrelated sessions, disabled claims caching, absent token expiry, legacy migration, expiration cleanup, and more than 1,000 cache entries.
• Tests with temporary Redis and NATS instances verify cache compatibility and shared revocations. NATS tests confirm that revocations survive the legacy bucket TTL.
• New NATS regressions reproduce both review findings before the fixes. They verify empty-cache startup, actual stream message counts after cleanup, concurrent key reuse, isolation between tables and buckets, authenticated maintenance, retry after failure, and cancellation.
• Proxy and OIDC tests pass, including race checks. Production identity providers and Redis Sentinel failover are not covered by these tests.

go test -mod=vendor -p 4 -short -timeout 3m -v ./services/proxy/... ./pkg/oidc/...
go test -mod=vendor -p 4 -race -short -timeout 3m -v ./services/proxy/pkg/command ./services/proxy/pkg/middleware ./services/proxy/pkg/staticroutes/... ./pkg/oidc/...
go test -mod=vendor -p 4 -race -short -timeout 3m -v ./services/proxy/... ./pkg/oidc/...

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation added

[codacy-production]

Not up to standards ⛔

🔴 Issues 1 critical

Alerts:
⚠ 1 issue (≤ 0 issues of at least minor severity)

Results:
1 new issue

Category	Results
Security	1 critical

View in Codacy

🟢 Metrics 283 complexity

Metric	Results
Complexity	283

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[zerox80]

Could you mark this finding as a false positive and rerun Codacy? It occurs in an integration test: the executable name is fixed to redis-server, arguments are passed without a shell, and the socket path comes from t.TempDir(). No untrusted request input reaches this call.

[dschmidt]

This means you're logged out from every session on every browser/device, right?
Is that really desirable/expected?

[zerox80]

This means you're logged out from every session on every browser/device, right? Is that really desirable/expected?

the scope depends on the logout token. When it contains a sid, only the tracked tokens belonging to that session are revoked; other sessions of the same user remain authenticated. When it contains only sub, all tracked sessions for that user are targeted, as specified by oidc back-channel logout.
That distinction already existed before this PR. The fix ensures that all previously accepted tokens within the targeted session(s), including tokens issued before a refresh, are invalidated. I verified the session isolation with HTTP regression tests.

[dschmidt]

Thanks for the clarification!