DongHyeonkaandClaude Opus 5
6c310c93b7
Neither client had a backchannel logout URL and the BFF has no oidcLogout configuration, so the three candidate paths all answer 302, which is the authentication redirect rather than a handler. Setting the URL on the identity provider alone changed nothing: with a live session, logging the user out emptied the Keycloak side and left the Redis session untouched. Reachability is not the blocker here, since a Keycloak pod fetches the app's public URL with a 200, but that is a property of this tailnet split-DNS lab and is the assumption most likely to fail in production, where it fails silently. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
C-2 — 백채널 로그아웃 증거
2026-09-04 16:30–16:55 KST
해설: docs/experiment-c2-backchannel-logout.md
| 파일 | 무엇을 보여주는가 |
|---|---|
01-current-state.txt |
두 클라이언트 모두 backchannelLogoutUrl 없음 · BFF 소스에 oidcLogout 없음 · 후보 경로 셋 다 302(핸들러 없음) |
02-configure-idp.txt |
IdP 쪽에만 backchannel.logout.url 설정 (점 표기는 실패, JSON 으로 성공) |
03-logout-attempt.txt |
살아 있는 세션(1)에 로그아웃 → IdP 세션 0, Redis 세션은 1 그대로. Keycloak·BFF 로그에 흔적 없음 |
04-reachability.txt |
Keycloak 파드가 app1.hyeonworks.com 에 HTTP 200 으로 닿는다 — 네트워크 문제가 아님 |
핵심 세 줄
- 백채널 로그아웃은 어느 쪽에도 구현되어 있지 않았다. C-1 이 관측한 "전파 안 됨"의 원인이다.
- IdP 쪽만 설정해도 소용없다. 받을 엔드포인트와
sid → 세션역인덱스가 앱에 있어야 한다. - 도달성이 숨은 전제다. 이 실험대는 닿지만, 앱이 사설망에 있으면 설정해도 조용히 실패한다.