docs: C-1 — killing the SSO session logs nobody out

One user session carries a client session per application, so visiting the second app skips the login screen. Deleting the identity provider session leaves both application sessions untouched and both apps keep serving, because the identity provider, the application session and the access token each have their own lifetime.

That inverts the B-2 finding: there the app session was cleared and the surviving SSO session let the user straight back in. Either way, clearing one side leaves the other. It also means an identity provider outage is a single point of failure for logging in, not for already-authenticated users, and the failure arrives late and all at once.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/evidence/c1-multi-app-sso/01-baseline.txt

@@ -0,0 +1,11 @@
+=== 깨끗한 상태로 초기화 ===
+DELETE 1
+
+=== 기준선 ===
+  Keycloak 온라인 세션: 4
+  Redis 키: 0
+
+=== 두 앱의 구조 ===
+  app1.hyeonworks.com  →  BFF        (서버 세션: Redis + PostgreSQL)
+  app2.hyeonworks.com  →  oauth2-proxy (쿠키 티켓 + Redis)
+  둘 다 realm keycloak-patterns 를 쓴다

docs/evidence/c1-multi-app-sso/02-after-app1-login.txt

@@ -0,0 +1,9 @@
+=== app1 로그인 직후 Keycloak 세션 ===
+     user_session_id      | client_sessions 
+--------------------------+-----------------
+ oqOjHekin4JU-BZjgQLjUByW |               1
+(1 row)
+
+  Redis 키: 1
+    bff:session:sessions:6e0d9af4-2c8f-47d2-bf83-8b1e9670c679
+  PostgreSQL authorized client: 1 행

docs/evidence/c1-multi-app-sso/03-after-app2-visit.txt

@@ -0,0 +1,20 @@
+=== app2 방문 후 — 로그인 화면 없이 통과했는가 ===
+     user_session_id      | client_sessions 
+--------------------------+-----------------
+ oqOjHekin4JU-BZjgQLjUByW |               2
+(1 row)
+
+
+=== 어느 클라이언트가 붙었는가 ===
+              client_id               |       name       
+--------------------------------------+------------------
+ 9055fa46-6abb-4d6d-a339-8a9183bbf26d | bff-confidential
+ 80431dbc-af81-4673-9790-ad06d1570b2e | oauth2-proxy
+(2 rows)
+
+
+=== 저장소 상태 ===
+  Redis 키:
+    _oauth2_proxy-6b028a70f69c8f0da9966eb36972dff2
+    bff:session:sessions:6e0d9af4-2c8f-47d2-bf83-8b1e9670c679
+  PostgreSQL authorized client: 1 행

docs/evidence/c1-multi-app-sso/04-sso-session-killed.txt

@@ -0,0 +1,25 @@
+=== ★ Keycloak 의 SSO 세션 하나를 죽인다 ===
+  남은 Keycloak 세션: 1
+
+=== 두 앱의 애플리케이션 세션은 그대로인가 ===
+  _oauth2_proxy-6b028a70f69c8f0da9966eb36972dff2
+  bff:session:sessions:6e0d9af4-2c8f-47d2-bf83-8b1e9670c679
+  PostgreSQL authorized client: 1 행
+
+  → IdP 세션은 없어졌는데 앱 세션은 남아 있다면, 두 계층의 수명이 어긋난 것이다
+=== 사용자 단위 로그아웃 (IdP 세션만 끊는다) ===
+  남은 Keycloak 세션: 1
+
+=== 앱 세션은 남아 있는가 ===
+  _oauth2_proxy-6b028a70f69c8f0da9966eb36972dff2
+  bff:session:sessions:6e0d9af4-2c8f-47d2-bf83-8b1e9670c679
+  PostgreSQL authorized client: 1 행
+=== 남은 세션의 realm 과 client ===
+     user_session_id      | realm  | clients 
+--------------------------+--------+---------
+ E1q5xI7tt4U_WhZpW7rEPIF2 | master |       1
+(1 row)
+
+
+=== 브라우저에서 두 앱을 다시 열면 어떻게 되는가 ===
+  (IdP 세션이 사라졌으면 재로그인이 필요해야 한다)

docs/evidence/c1-multi-app-sso/README.md

@@ -0,0 +1,19 @@
+# C-1 — 다중 앱 SSO 증거
+
+2026-09-04 16:15–16:30 KST
+해설: [`docs/experiment-c1-multi-app-sso.md`](../../experiment-c1-multi-app-sso.md)
+
+| 파일 | 무엇을 보여주는가 |
+|---|---|
+| `01-baseline.txt` | 초기화 시도 — `logout-all` 이 안 먹어 세션 4개가 남았다 |
+| `02-after-app1-login.txt` | app1 로그인 후 — user session 1 · client session 1 · Redis 1 · DB 1행 |
+| `03-after-app2-visit.txt` | **app2 방문 후 client session 1 → 2**, `bff-confidential` 과 `oauth2-proxy` 가 같은 user session 에 붙음. Redis 에 두 종류 세션 |
+| `04-sso-session-killed.txt` | IdP 세션 삭제 후 — **앱 세션 셋 다 남아 있다**. realm 을 join 해 보고서야 남은 것이 master 세션임을 확인 |
+| `c1-sso-app2-no-login-screen.png` | app2 가 로그인 화면 없이 열린 화면 |
+| `c1-apps-alive-after-idp-logout.png` | **IdP 세션을 죽인 뒤에도 그대로 열리는 화면** |
+
+## 핵심 세 줄
+
+1. **SSO 는 user session 1개에 client session N개** 구조다 — A-3(전체 소실)과 B-3(client 만 제거)의 차이가 여기서 의미를 갖는다.
+2. **IdP 세션을 죽여도 두 앱은 계속 동작한다.** 세 층(IdP·앱·토큰)의 수명이 각자이기 때문이다.
+3. **IdP 는 "로그인 경로"의 단일 장애점이지 "이미 로그인한 사용자"의 단일 장애점이 아니다.** 장애는 앱 세션 수명만큼 지연되어 몰려온다.