docs: B-3 — concurrent refresh does not lose a race, it destroys the session

Five simultaneous refreshes with one token return a single 200, and that winner's new token is already dead. Reuse detection removes the client session while the user session stays, which is why the other responses read Session doesn't have required client rather than a reuse error.

Comparing policies shows rotation off passes all five and keeps the session, while raising refreshTokenMaxReuse to one still destroys it. Since no retry can recover a removed client session, Q2's own criterion resolves to a lock, and a database row lock is the natural place because its lifetime is tied to the connection.

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

.playwright-mcp/console-2026-09-04T05-00-51-720Z.log

@@ -0,0 +1 @@
+[     236ms] [ERROR] Failed to load resource: the server responded with a status of 500 () @ https://app1.hyeonworks.com/bff/api/me:0

.playwright-mcp/console-2026-09-04T05-02-32-624Z.log

@@ -0,0 +1,2 @@
+[    7292ms] [ERROR] Access to fetch at 'https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/auth?response_type=code&client_id=bff-confidential&scope=openid%20profile%20email&state=WWc76H7TY73Fbsdc41B2nRD5exkXqHcohLh4WdJB4AA%3D&redirect_uri=https://app1.hyeonworks.com/login/oauth2/code/keycloak&nonce=A4TXweuKS4Y5HdZ63rLJUez1ZOyI2em6zs3OIfTXLFo&code_challenge=wPr8PXG0lcUvie7Wo91YrVMhOUYq0KtEU4PxVJ0_CWA&code_challenge_method=S256' (redirected from 'https://app1.hyeonworks.com/bff/api/me') from origin 'https://app1.hyeonworks.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. @ https://app1.hyeonworks.com/bff/token-boundary:0
+[    7293ms] [ERROR] Failed to load resource: net::ERR_FAILED @ https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/auth?response_type=code&client_id=bff-confidential&scope=openid%20profile%20email&state=WWc76H7TY73Fbsdc41B2nRD5exkXqHcohLh4WdJB4AA%3D&redirect_uri=https://app1.hyeonworks.com/login/oauth2/code/keycloak&nonce=A4TXweuKS4Y5HdZ63rLJUez1ZOyI2em6zs3OIfTXLFo&code_challenge=wPr8PXG0lcUvie7Wo91YrVMhOUYq0KtEU4PxVJ0_CWA&code_challenge_method=S256:0

.playwright-mcp/console-2026-09-04T05-02-45-161Z.log

@@ -0,0 +1,2 @@
+[    6726ms] [ERROR] Access to fetch at 'https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/auth?response_type=code&client_id=bff-confidential&scope=openid%20profile%20email&state=GGupuPr3ZklKp8ah99r7h7mNHEq9yTsEWZr85WyXevE%3D&redirect_uri=https://app1.hyeonworks.com/login/oauth2/code/keycloak&nonce=rPVvEOvG7rzssAjR7pP67qNvoY2W6ZVpIpKYz1LGoU8&code_challenge=qoKRLRrzB7z9CU_rlaAxJ7UYcRZswyqmDi8PgxmaWM0&code_challenge_method=S256' (redirected from 'https://app1.hyeonworks.com/bff/api/me') from origin 'https://app1.hyeonworks.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. @ https://app1.hyeonworks.com/:0
+[    6726ms] [ERROR] Failed to load resource: net::ERR_FAILED @ https://auth.hyeonworks.com/realms/keycloak-patterns/protocol/openid-connect/auth?response_type=code&client_id=bff-confidential&scope=openid%20profile%20email&state=GGupuPr3ZklKp8ah99r7h7mNHEq9yTsEWZr85WyXevE%3D&redirect_uri=https://app1.hyeonworks.com/login/oauth2/code/keycloak&nonce=rPVvEOvG7rzssAjR7pP67qNvoY2W6ZVpIpKYz1LGoU8&code_challenge=qoKRLRrzB7z9CU_rlaAxJ7UYcRZswyqmDi8PgxmaWM0&code_challenge_method=S256:0

.playwright-mcp/console-2026-09-04T05-12-36-323Z.log

@@ -0,0 +1,2 @@
+[    6898ms] [ERROR] Failed to load resource: the server responded with a status of 403 () @ https://app1.hyeonworks.com/logout:0
+[   23950ms] [ERROR] Failed to load resource: the server responded with a status of 403 () @ https://app1.hyeonworks.com/logout:0

.playwright-mcp/page-2026-09-04T05-00-02-742Z.yml

@@ -0,0 +1,7 @@
+- main [ref=f29e2]:
+  - heading "AP3 · Backend-for-Frontend" [level=1] [ref=f29e3]
+  - paragraph [ref=f29e4]: 브라우저에는 OAuth token이 전혀 전달되지 않습니다. HttpOnly session cookie로 BFF만 호출하고, BFF가 서버 보관 access token을 Resource Server 요청에 붙입니다.
+  - button "Keycloak 로그인" [ref=f29e5] [cursor=pointer]
+  - button "token 경계 확인" [ref=f29e6] [cursor=pointer]
+  - button "BFF 경유 API 호출" [ref=f29e7] [cursor=pointer]
+  - button "CSRF token으로 상태 변경" [ref=f29e8] [cursor=pointer]

.playwright-mcp/page-2026-09-04T05-00-09-772Z.yml

@@ -0,0 +1 @@
+- generic [active] [ref=f30e1]: "{\"pattern\":\"AP3-backend-for-frontend\",\"principal\":\"labuser\",\"accessTokenStoredOnServer\":false,\"refreshTokenStoredOnServer\":false,\"browserTokenCount\":0,\"csrfProtectionEnabled\":true}"

.playwright-mcp/page-2026-09-04T05-00-52-003Z.yml

@@ -0,0 +1,5 @@
+- generic [active] [ref=f31e1]:
+  - heading "Whitelabel Error Page" [level=1] [ref=f31e2]
+  - paragraph [ref=f31e3]: This application has no explicit mapping for /error, so you are seeing this as a fallback.
+  - generic [ref=f31e4]: Fri Sep 04 05:00:51 GMT 2026
+  - generic [ref=f31e5]: There was an unexpected error (type=Internal Server Error, status=500).

.playwright-mcp/page-2026-09-04T05-02-33-239Z.yml

@@ -0,0 +1 @@
+- generic [active] [ref=f32e1]: "{\"pattern\":\"AP3-backend-for-frontend\",\"principal\":\"labuser\",\"accessTokenStoredOnServer\":false,\"refreshTokenStoredOnServer\":false,\"browserTokenCount\":0,\"csrfProtectionEnabled\":true}"

.playwright-mcp/page-2026-09-04T05-02-45-383Z.yml

@@ -0,0 +1,7 @@
+- main [ref=f33e2]:
+  - heading "AP3 · Backend-for-Frontend" [level=1] [ref=f33e3]
+  - paragraph [ref=f33e4]: 브라우저에는 OAuth token이 전혀 전달되지 않습니다. HttpOnly session cookie로 BFF만 호출하고, BFF가 서버 보관 access token을 Resource Server 요청에 붙입니다.
+  - button "Keycloak 로그인" [ref=f33e5] [cursor=pointer]
+  - button "token 경계 확인" [ref=f33e6] [cursor=pointer]
+  - button "BFF 경유 API 호출" [ref=f33e7] [cursor=pointer]
+  - button "CSRF token으로 상태 변경" [ref=f33e8] [cursor=pointer]

.playwright-mcp/page-2026-09-04T05-03-13-061Z.yml

@@ -0,0 +1 @@
+- generic [active] [ref=f34e1]: "{\"pattern\":\"AP3-backend-for-frontend\",\"principal\":\"labuser\",\"accessTokenStoredOnServer\":false,\"refreshTokenStoredOnServer\":false,\"browserTokenCount\":0,\"csrfProtectionEnabled\":true}"

.playwright-mcp/page-2026-09-04T05-10-19-868Z.yml

@@ -0,0 +1 @@
+- generic [active] [ref=f35e1]: "{\"pattern\":\"AP3-backend-for-frontend\",\"principal\":\"labuser\",\"accessTokenStoredOnServer\":false,\"refreshTokenStoredOnServer\":false,\"browserTokenCount\":0,\"csrfProtectionEnabled\":true}"

.playwright-mcp/page-2026-09-04T05-10-47-333Z.yml

@@ -0,0 +1,7 @@
+- main [ref=f36e2]:
+  - heading "AP3 · Backend-for-Frontend" [level=1] [ref=f36e3]
+  - paragraph [ref=f36e4]: 브라우저에는 OAuth token이 전혀 전달되지 않습니다. HttpOnly session cookie로 BFF만 호출하고, BFF가 서버 보관 access token을 Resource Server 요청에 붙입니다.
+  - button "Keycloak 로그인" [ref=f36e5] [cursor=pointer]
+  - button "token 경계 확인" [ref=f36e6] [cursor=pointer]
+  - button "BFF 경유 API 호출" [ref=f36e7] [cursor=pointer]
+  - button "CSRF token으로 상태 변경" [ref=f36e8] [cursor=pointer]

.playwright-mcp/page-2026-09-04T05-11-44-142Z.yml

@@ -0,0 +1 @@
+- generic [active] [ref=f37e1]: "{\"pattern\":\"AP3-backend-for-frontend\",\"principal\":\"labuser\",\"accessTokenStoredOnServer\":true,\"refreshTokenStoredOnServer\":true,\"browserTokenCount\":0,\"csrfProtectionEnabled\":true}"

.playwright-mcp/page-2026-09-04T05-12-13-198Z.yml

@@ -0,0 +1,7 @@
+- main [ref=f38e2]:
+  - heading "AP3 · Backend-for-Frontend" [level=1] [ref=f38e3]
+  - paragraph [ref=f38e4]: 브라우저에는 OAuth token이 전혀 전달되지 않습니다. HttpOnly session cookie로 BFF만 호출하고, BFF가 서버 보관 access token을 Resource Server 요청에 붙입니다.
+  - button "Keycloak 로그인" [ref=f38e5] [cursor=pointer]
+  - button "token 경계 확인" [ref=f38e6] [cursor=pointer]
+  - button "BFF 경유 API 호출" [ref=f38e7] [cursor=pointer]
+  - button "CSRF token으로 상태 변경" [ref=f38e8] [cursor=pointer]

.playwright-mcp/page-2026-09-04T05-12-36-478Z.yml

@@ -0,0 +1,7 @@
+- main [ref=f39e2]:
+  - heading "AP3 · Backend-for-Frontend" [level=1] [ref=f39e3]
+  - paragraph [ref=f39e4]: 브라우저에는 OAuth token이 전혀 전달되지 않습니다. HttpOnly session cookie로 BFF만 호출하고, BFF가 서버 보관 access token을 Resource Server 요청에 붙입니다.
+  - button "Keycloak 로그인" [ref=f39e5] [cursor=pointer]
+  - button "token 경계 확인" [ref=f39e6] [cursor=pointer]
+  - button "BFF 경유 API 호출" [ref=f39e7] [cursor=pointer]
+  - button "CSRF token으로 상태 변경" [ref=f39e8] [cursor=pointer]

bff/pom.xml

@@ -29,6 +29,38 @@
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-starter-oauth2-client</artifactId>
         </dependency>
+
+        <!-- B-1: Application Session 을 Redis 로 옮긴다.
+             spring-session-data-redis 가 SessionRepository 를 갈아끼우고,
+             spring-boot-starter-data-redis 가 연결(Lettuce)을 제공한다.
+             둘 다 있어야 자동구성이 걸린다 — 하나만 넣으면 조용히 in-memory 로 남는다. -->
+        <dependency>
+            <groupId>org.springframework.session</groupId>
+            <artifactId>spring-session-data-redis</artifactId>
+        </dependency>
+        <dependency>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-starter-data-redis</artifactId>
+        </dependency>
+
+        <!-- B-2: OAuth2AuthorizedClient 를 PostgreSQL 로 옮긴다.
+             Q3 가 후보로 든 "Redis 와 JDBC 중 무엇" 에서 JDBC 쪽이며,
+             JdbcOAuth2AuthorizedClientService 는 같은 인터페이스라
+             컨트롤러를 바꾸지 않아도 된다. -->
+        <dependency>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-starter-jdbc</artifactId>
+        </dependency>
+        <dependency>
+            <groupId>org.postgresql</groupId>
+            <artifactId>postgresql</artifactId>
+            <scope>runtime</scope>
+        </dependency>
+        <dependency>
+            <groupId>com.h2database</groupId>
+            <artifactId>h2</artifactId>
+            <scope>test</scope>
+        </dependency>
         <dependency>
             <groupId>org.springframework.boot</groupId>
             <artifactId>spring-boot-starter-web</artifactId>

bff/src/main/java/com/example/keycloakpattern/bff/SecurityConfig.java

@@ -8,15 +8,38 @@ import org.springframework.security.oauth2.client.OAuth2AuthorizedClientManager;
 import org.springframework.security.oauth2.client.OAuth2AuthorizedClientProvider;
 import org.springframework.security.oauth2.client.OAuth2AuthorizedClientProviderBuilder;
 import org.springframework.security.oauth2.client.OAuth2AuthorizedClientService;
+import org.springframework.security.oauth2.client.JdbcOAuth2AuthorizedClientService;
 import org.springframework.security.oauth2.client.registration.ClientRegistrationRepository;
 import org.springframework.security.oauth2.client.web.DefaultOAuth2AuthorizationRequestResolver;
 import org.springframework.security.oauth2.client.web.OAuth2AuthorizationRequestCustomizers;
 import org.springframework.security.web.SecurityFilterChain;
 import org.springframework.security.web.csrf.CookieCsrfTokenRepository;
+import org.springframework.jdbc.core.JdbcOperations;
 
 @Configuration
 public class SecurityConfig {
 
+    /**
+     * B-2 — authorized client 를 프로세스 메모리에서 PostgreSQL 로 옮긴다.
+     *
+     * B-1 에서 Application Session 만 Redis 로 옮겼더니, 사용자는 로그인
+     * 상태로 보이는데 BFF 에는 access token 이 없는 상태가 만들어졌다.
+     * 두 상태의 저장소를 **각각** 정해야 한다는 Q3 의 지적이 그대로 나타난 것이다.
+     *
+     * 주의 — 이것이 고치는 것과 고치지 못하는 것이 다르다.
+     *   고친다   : 인스턴스 간 공유. 어느 replica 로 가도 같은 토큰을 본다.
+     *   못 고친다: 조회 키. JdbcOAuth2AuthorizedClientService 도
+     *              (clientRegistrationId, principalName) 으로 찾으므로
+     *              같은 사용자의 두 브라우저는 여전히 한 항목을 공유한다.
+     */
+    @Bean
+    OAuth2AuthorizedClientService authorizedClientService(
+        JdbcOperations jdbcOperations,
+        ClientRegistrationRepository clientRegistrationRepository
+    ) {
+        return new JdbcOAuth2AuthorizedClientService(jdbcOperations, clientRegistrationRepository);
+    }
+
     @Bean
     SecurityFilterChain bffSecurity(
         HttpSecurity http,

bff/src/main/resources/application.yml

@@ -10,6 +10,34 @@ server:
 spring:
   application:
     name: keycloak-bff
+  datasource:
+    # B-2: authorized client 전용. Keycloak 과 같은 PostgreSQL 인스턴스지만
+    # 테이블이 다르다(oauth2_authorized_client). 운영이라면 분리를 검토한다.
+    url: ${BFF_DB_URL:jdbc:postgresql://localhost:5432/keycloak}
+    username: ${BFF_DB_USER:keycloak}
+    password: ${BFF_DB_PASSWORD:keycloak}
+  sql:
+    init:
+      # Spring Security 가 제공하는 DDL 을 그대로 쓴다.
+      # always 로 두면 매 기동마다 실행되므로 CREATE TABLE IF NOT EXISTS 가 아닌
+      # 스크립트에서는 실패한다 → continue-on-error 로 넘긴다.
+      mode: ${SPRING_SQL_INIT_MODE:always}
+      # ★ PostgreSQL 은 -postgres 판본을 써야 한다. 기본 판본은 `blob` 타입을
+      #   쓰는데 PostgreSQL 에는 그 타입이 없다(`bytea` 다). continue-on-error 가
+      #   그 실패를 삼켜서 "테이블이 조용히 안 생기는" 상태가 됐었다.
+      schema-locations: classpath:org/springframework/security/oauth2/client/oauth2-client-schema-postgres.sql
+      continue-on-error: true
+  data:
+    redis:
+      host: ${REDIS_HOST:localhost}
+      port: ${REDIS_PORT:6379}
+  session:
+    # Application Session 만 Redis 로 간다. OAuth2AuthorizedClient 는
+    # 이 설정과 무관하며 여전히 InMemory 다 — 조회 키가 다르기 때문이다(B-0).
+    store-type: ${SPRING_SESSION_STORE_TYPE:redis}
+    timeout: ${SPRING_SESSION_TIMEOUT:30m}
+    redis:
+      namespace: bff:session
   security:
     oauth2:
       client:

bff/src/test/java/com/example/keycloakpattern/bff/BffControllerTest.java

@@ -24,6 +24,15 @@ import org.springframework.test.web.servlet.MockMvc;
 
 @SpringBootTest(properties = {
     "KEYCLOAK_CLIENT_SECRET=test-only-secret",
+    // 테스트는 Redis 를 띄우지 않는다. store-type=none 이면 자동구성이
+    // 서블릿 컨테이너 기본 세션으로 되돌아가 컨텍스트가 뜬다.
+    "spring.session.store-type=none",
+    // 테스트에는 PostgreSQL 이 없다. H2 로 대신하고 Spring Security 의
+    // DDL 을 그대로 태워 JdbcOAuth2AuthorizedClientService 가 뜨게 한다.
+    "spring.datasource.url=jdbc:h2:mem:bfftest;DB_CLOSE_DELAY=-1",
+    "spring.datasource.username=sa",
+    "spring.datasource.password=",
+    "spring.sql.init.mode=always",
     "resource-api.base-url=http://127.0.0.1:9"
 })
 @AutoConfigureMockMvc

deploy/lab/k8s/bff-redis.yaml

@@ -92,6 +92,14 @@ spec:
           whenUnsatisfiable: ScheduleAnyway
           labelSelector:
             matchLabels: { app: bff }
+      # 쿠버네티스는 같은 네임스페이스의 Service 마다 Docker link 시절의
+      # 환경변수를 자동 주입한다: REDIS_PORT=tcp://10.43.57.116:6379.
+      # 그것이 application.yml 의 ${REDIS_PORT:6379} 를 덮어써서 기동이 실패했다.
+      #   Failed to bind properties under 'spring.data.redis.port' to int:
+      #     Value: "tcp://10.43.57.116:6379"
+      # 이 주입 자체를 끄는 것이 근본 처방이다. 이름을 바꿔 피하면 다음 사람이
+      # 같은 함정에 다시 빠진다.
+      enableServiceLinks: false
       containers:
         - name: bff
           image: keycloak-pattern-bff:lab
@@ -107,8 +115,11 @@ spec:
               value: https://auth.hyeonworks.com/realms/keycloak-patterns
             - name: KC_ISSUER_INTERNAL
               value: http://keycloak.keycloak-lab.svc:8080/realms/keycloak-patterns
+            # echo 는 header-lab 네임스페이스의 8081 이다. 다른 네임스페이스의
+            # 서비스는 <svc>.<ns>.svc 로 부른다. 이름을 틀리면 500 이 나는데
+            # 원인은 UnresolvedAddressException 이지 토큰 문제가 아니다.
             - name: RESOURCE_API_BASE_URL
-              value: http://echo.keycloak-lab.svc:8080
+              value: http://echo.header-lab.svc:8081
             - name: KEYCLOAK_CLIENT_SECRET
               valueFrom:
                 secretKeyRef: { name: bff-secrets, key: KEYCLOAK_CLIENT_SECRET }
@@ -117,6 +128,24 @@ spec:
             # it builds comes back as http:// and Keycloak rejects it.
             - name: SERVER_FORWARD_HEADERS_STRATEGY
               value: native
+            # B-1: Application Session 을 Redis 로 옮긴다.
+            # OAuth2AuthorizedClient 는 이것으로 옮겨지지 않는다 — 조회 키가
+            # 다르기 때문이며, B-0 에서 확인한 사실이다.
+            - name: SPRING_SESSION_STORE_TYPE
+              value: redis
+            - name: REDIS_HOST
+              value: redis.keycloak-lab.svc
+            - name: REDIS_PORT
+              value: "6379"
+            # B-2: authorized client 는 PostgreSQL 로. 세션(Redis)과 다른
+            # 저장소를 쓰는 것이 Q3 가 말한 "각각 설계한다"의 실물이다.
+            - name: BFF_DB_URL
+              value: jdbc:postgresql://postgres.keycloak-lab.svc:5432/keycloak
+            - name: BFF_DB_USER
+              value: keycloak
+            - name: BFF_DB_PASSWORD
+              valueFrom:
+                secretKeyRef: { name: keycloak-lab-secrets, key: POSTGRES_PASSWORD }
             - name: JAVA_TOOL_OPTIONS
               value: "-Xms128m -Xmx320m"
           readinessProbe:

docs/evidence/b1-redis-session-store/01-servicelinks-trap.txt

@@ -0,0 +1,5 @@
+deployment.apps/bff configured
+deployment "bff" successfully rolled out
+bff-576d869c6d-bshvl   true   kc-lab-2
+bff-695646ddb-kzs9k    true   kc-lab-1
+bff-695646ddb-vjqzf    true   kc-lab-2

docs/evidence/b1-redis-session-store/02-autoconfig-after.txt

@@ -0,0 +1,64 @@
+=== B-1 — Redis 를 붙인 뒤 자동구성이 실제로 바뀌었는가 ===
+  빈 수: 321 → 402  (+81)
+
+  --- 세션 저장소 관련 (새로 생긴 것) ---
+    ★ cookieSerializer                           -> DefaultCookieSerializer
+    ★ org.springframework.boot.autoconfigure.session.RedisSessionConfiguration -> RedisSessionConfiguration
+    ★ org.springframework.boot.autoconfigure.session.RedisSessionConfiguration$DefaultRedisSessionConfiguration -> RedisSessionConfiguration$DefaultRedisSessionConfiguration
+    ★ org.springframework.boot.autoconfigure.session.SessionAutoConfiguration -> SessionAutoConfiguration
+    ★ org.springframework.boot.autoconfigure.session.SessionAutoConfiguration$ServletSessionConfiguration -> SessionAutoConfiguration$ServletSessionConfiguration
+    ★ org.springframework.boot.autoconfigure.session.SessionAutoConfiguration$ServletSessionConfiguration$RememberMeServicesConfiguration -> SessionAutoConfiguration$ServletSessionConfiguration$RememberMeServicesConfiguration
+    ★ org.springframework.boot.autoconfigure.session.SessionAutoConfiguration$ServletSessionConfiguration$ServletSessionRepositoryConfiguration -> SessionAutoConfiguration$ServletSessionConfiguration$ServletSessionRepositoryConfiguration
+    ★ org.springframework.boot.autoconfigure.session.SessionRepositoryFilterConfiguration -> SessionRepositoryFilterConfiguration
+    ★ org.springframework.session.config.annotation.web.http.SpringHttpSessionConfiguration -> SpringHttpSessionConfiguration
+    ★ org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration -> RedisHttpSessionConfiguration
+    ★ rememberMeServicesCookieSerializerCustomizer -> SessionAutoConfiguration$ServletSessionConfiguration$RememberMeServicesConfiguration$$Lambda/0x00007f364e69fa60
+    ★ sessionEventHttpSessionListenerAdapter     -> SessionEventHttpSessionListenerAdapter
+    ★ sessionRepository                          -> RedisSessionRepository
+    ★ sessionRepositoryFilterRegistration        -> DelegatingFilterProxyRegistrationBean
+    ★ spring.session-org.springframework.boot.autoconfigure.session.SessionProperties -> SessionProperties
+    ★ spring.session.redis-org.springframework.boot.autoconfigure.session.RedisSessionProperties -> RedisSessionProperties
+    ★ springBootSessionRepositoryCustomizer      -> RedisSessionConfiguration$DefaultRedisSessionConfiguration$$Lambda/0x00007f364e6a4a68
+    ★ springSessionRepositoryFilter              -> SessionRepositoryFilter
+
+  --- OAuth2 authorized client — 바뀌었는가? ---
+    authorizedClientService
+      before: InMemoryOAuth2AuthorizedClientService
+      after : InMemoryOAuth2AuthorizedClientService    그대로 — Redis 로 안 옮겨졌다
+    authorizedClientRepository
+      before: AuthenticatedPrincipalOAuth2AuthorizedClientRepository
+      after : AuthenticatedPrincipalOAuth2AuthorizedClientRepository    그대로 — Redis 로 안 옮겨졌다
+    authorizedClientManager
+      before: AuthorizedClientServiceOAuth2AuthorizedClientManager
+      after : AuthorizedClientServiceOAuth2AuthorizedClientManager    그대로 — Redis 로 안 옮겨졌다
+
+  --- Redis 연결 빈 (새로 생긴 것) ---
+    ★ keyValueMappingContext                     -> RedisMappingContext
+    ★ lettuceMetrics                             -> LettuceMetricsAutoConfiguration$$Lambda/0x00007f364e56f4d0
+    ★ org.springframework.boot.actuate.autoconfigure.data.redis.RedisHealthContributorAutoConfiguration -> RedisHealthContributorAutoConfiguration
+    ★ org.springframework.boot.actuate.autoconfigure.data.redis.RedisReactiveHealthContributorAutoConfiguration -> RedisReactiveHealthContributorAutoConfiguration
+    ★ org.springframework.boot.actuate.autoconfigure.metrics.redis.LettuceMetricsAutoConfiguration -> LettuceMetricsAutoConfiguration
+    ★ org.springframework.boot.autoconfigure.data.redis.LettuceConnectionConfiguration -> LettuceConnectionConfiguration
+    ★ org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration -> RedisAutoConfiguration
+    ★ org.springframework.boot.autoconfigure.data.redis.RedisReactiveAutoConfiguration -> RedisReactiveAutoConfiguration
+    ★ org.springframework.boot.autoconfigure.data.redis.RedisRepositoriesAutoConfiguration -> RedisRepositoriesAutoConfiguration
+    ★ org.springframework.boot.autoconfigure.session.RedisSessionConfiguration -> RedisSessionConfiguration
+    ★ org.springframework.boot.autoconfigure.session.RedisSessionConfiguration$DefaultRedisSessionConfiguration -> RedisSessionConfiguration$DefaultRedisSessionConfiguration
+    ★ org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration -> RedisHttpSessionConfiguration
+    ★ reactiveRedisTemplate                      -> ReactiveRedisTemplate
+    ★ reactiveStringRedisTemplate                -> ReactiveStringRedisTemplate
+    ★ redisConnectionDetails                     -> PropertiesRedisConnectionDetails
+    ★ redisConnectionFactory                     -> LettuceConnectionFactory
+    ★ redisConverter                             -> MappingRedisConverter
+    ★ redisCustomConversions                     -> RedisCustomConversions
+    ★ redisHealthContributor                     -> RedisReactiveHealthIndicator
+    ★ redisKeyValueAdapter                       -> RedisKeyValueAdapter
+    ★ redisKeyValueTemplate                      -> RedisKeyValueTemplate
+    ★ redisMappingConfiguration#0                -> MappingConfiguration
+    ★ redisReferenceResolver                     -> ReferenceResolverImpl
+    ★ redisTemplate                              -> RedisTemplate
+    ★ sessionRepository                          -> RedisSessionRepository
+    ★ spring.data.redis-org.springframework.boot.autoconfigure.data.redis.RedisProperties -> RedisProperties
+    ★ spring.session.redis-org.springframework.boot.autoconfigure.session.RedisSessionProperties -> RedisSessionProperties
+    ★ springBootSessionRepositoryCustomizer      -> RedisSessionConfiguration$DefaultRedisSessionConfiguration$$Lambda/0x00007f364e6a4a68
+    ★ stringRedisTemplate                        -> StringRedisTemplate

docs/evidence/b1-redis-session-store/03-redis-contents.txt

@@ -0,0 +1,21 @@
+=== Redis 에 무엇이 들어 있는가 ===
+bff:session:sessions:8963b6de-3564-4775-9ccd-1ee9616b83ae
+  총 키 수: 1
+
+=== 세션 키의 내용 — refresh token 이 있는가 (Q3 검증 2번) ===
+  키: bff:session:sessions:8963b6de-3564-4775-9ccd-1ee9616b83ae
+  타입: hash
+    필드: sessionAttr:SPRING_SECURITY_CONTEXT
+    필드: sessionAttr:SPRING_SECURITY_SAVED_REQUEST
+    필드: sessionAttr:SPRING_SECURITY_LAST_EXCEPTION
+    필드: sessionAttr:org.springframework.security.oauth2.client.web.HttpSessionOAuth2AuthorizationRequestRepository.AUTHORIZATION_REQUEST
+    필드: lastAccessedTime
+    필드: maxInactiveInterval
+    필드: creationTime
+
+=== 필드 값에 토큰 문자열이 보이는가 ===
+ 1) "sessionAttr:SPRING_SECURITY_CONTEXT"
+ 2) "\xac\xed\x00\x05sr\x00=org.springframework.security.core.context.SecurityContextImpl\x00\x00\x00\x00\x00\x00\x02l\x02\x00\x01L\x00\x0eauthenticationt\x002Lorg/springframework/security/core/Authentication;xpsr\x00Sorg.springframework.security.oauth2.client.authentication.OAuth2AuthenticationToken\x00\x00\x00\x00\x00\x00\x02l\x02\x00\x02L\x00\x1eauthorizedClientRegistrationIdt\x00\x12Ljava/lang/String;L\x00\tprincipalt\x00:Lorg/springframework/security/oauth2/core/user/OAuth2User;xr\x00Gorg.springframework.security.authentication.AbstractAuthenticationToken\xd3\xaa(~nGd\x0e\x02\x00\x03Z\x00\rauthenticatedL\x00\x0bauthoritiest\x00\x16Ljava/util/Collection;L\x00\adetailst\x00\x12Ljava/lang/Object;xp\x01sr\x00&java.util.Collections$UnmodifiableList\xfc\x0f%1\xb5\xec\x8e\x10\x02\x00\x01L\x00\x04listt\x00\x10Ljava/util/List;xr\x00,java.util.Collect
+
+=== TTL (Q3 검증 3번 — session TTL) ===
+  TTL: 1772 초

docs/evidence/b1-redis-session-store/README.md

@@ -0,0 +1,18 @@
+# B-1 — Redis 세션 저장소 전환 증거
+
+2026-09-04 14:50–15:05 KST
+해설: [`docs/experiment-b1-redis-session-store.md`](../../experiment-b1-redis-session-store.md)
+
+| 파일 | 무엇을 보여주는가 |
+|---|---|
+| `01-servicelinks-trap.txt` | `enableServiceLinks: false` 적용 후 롤아웃 성공 — 쿠버네티스가 주입한 `REDIS_PORT=tcp://...` 가 설정을 덮어쓴 문제 |
+| `02-autoconfig-after.txt` | **핵심** — 빈 321→402(+81). `sessionRepository → RedisSessionRepository` 로 바뀌었지만 **`authorizedClientService` 는 `InMemory` 그대로** |
+| `03-redis-contents.txt` | Redis 키 1개, 필드는 `SPRING_SECURITY_CONTEXT` 뿐. **토큰 없음.** Java 직렬화(`\xac\xed`), TTL 1772초 |
+| `b1-login-works-two-replicas.png` | 전환 직후 `accessTokenStoredOnServer: false` |
+| `b1-token-boundary-after-redis.png` | 파드 전면 교체 후 — `principal: labuser` 는 살아남고 토큰만 사라진 상태 |
+
+## 핵심 세 줄
+
+1. **세션은 옮겨졌고 토큰은 안 옮겨졌다.** 빈 81개가 늘었는데 authorized client 관련은 하나도 안 바뀌었다.
+2. **refresh token 은 Redis 에 평문으로 있는 게 아니라 아예 없다.** 암호화를 고민하기 전에 이걸 알아야 한다.
+3. **"로그인은 되어 있는데 아무것도 못 하는" 상태가 만들어진다** — 완전 로그아웃보다 나쁘다.

docs/evidence/b2-multi-instance-session/01-jdbc-store-deploy.txt

@@ -0,0 +1,8 @@
+deployment.apps/bff configured
+deployment "bff" successfully rolled out
+bff-555df79c97-6j86w   1/1   Running       0     44s
+bff-555df79c97-vgg6g   1/1   Running       0     22s
+
+=== oauth2_authorized_client 테이블이 생겼는가 ===
+Did not find any relation named "oauth2_authorized_client".
+command terminated with exit code 1

docs/evidence/b2-multi-instance-session/02-schema.txt

@@ -0,0 +1,33 @@
+=== PostgreSQL 전용 스키마 ===
+CREATE TABLE oauth2_authorized_client (
+  client_registration_id varchar(100) NOT NULL,
+  principal_name varchar(200) NOT NULL,
+  access_token_type varchar(100) NOT NULL,
+  access_token_value bytea NOT NULL,
+  access_token_issued_at timestamp NOT NULL,
+  access_token_expires_at timestamp NOT NULL,
+  access_token_scopes varchar(1000) DEFAULT NULL,
+  refresh_token_value bytea DEFAULT NULL,
+  refresh_token_issued_at timestamp DEFAULT NULL,
+  created_at timestamp DEFAULT CURRENT_TIMESTAMP NOT NULL,
+  PRIMARY KEY (client_registration_id, principal_name)
+);
+
+=== 적용 ===
+CREATE TABLE
+                                Table "public.oauth2_authorized_client"
+         Column          |            Type             | Collation | Nullable |         Default         
+-------------------------+-----------------------------+-----------+----------+-------------------------
+ client_registration_id  | character varying(100)      |           | not null | 
+ principal_name          | character varying(200)      |           | not null | 
+ access_token_type       | character varying(100)      |           | not null | 
+ access_token_value      | bytea                       |           | not null | 
+ access_token_issued_at  | timestamp without time zone |           | not null | 
+ access_token_expires_at | timestamp without time zone |           | not null | 
+ access_token_scopes     | character varying(1000)     |           |          | NULL::character varying
+ refresh_token_value     | bytea                       |           |          | 
+ refresh_token_issued_at | timestamp without time zone |           |          | 
+ created_at              | timestamp without time zone |           | not null | CURRENT_TIMESTAMP
+Indexes:
+    "oauth2_authorized_client_pkey" PRIMARY KEY, btree (client_registration_id, principal_name)
+

docs/evidence/b2-multi-instance-session/03-plaintext-tokens.txt

@@ -0,0 +1,20 @@
+=== Q3 검증 2번 — 저장소를 직접 열어 refresh token 이 평문인가 ===
+eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJlMmUzZDZkMy0yNzQyLTRhYWItYjk4Ni02ZDU2ZDM5MDk1ZDEifQ.eyJleHAiOjE3ODg1MDA0NDYsImlhdCI6MTc4ODQ5ODY0NiwianRpIjoiNTQwOTZmYTQtZWRjNi1iZjZkLWE4OGMtZDJhNjEzOGJjNmVlIiwiaXNzIjoiaHR0cHM6Ly9hdXRoLmh5ZW9ud29ya3MuY29tL3JlYWxtcy9rZXljbG9hay1wYXR0ZXJucyIsImF1ZCI6I
+
+=== access token 도 ===
+eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJPWS1jYVlETkdvUDRITUF6LVE5VVBUVS1ETTFpODk2TnV6VVp1NmdmQ3FNIn0.eyJleHAi
+
+=== 그 문자열이 실제 JWT 인지 — 헤더를 디코드 ===
+  File "<string>", line 3
+    h=open(/tmp/hdr.txt).read().strip()
+           ^
+SyntaxError: invalid syntax
+
+=== 저장된 바이트를 그대로 디코드한 결과 ===
+  refresh_token 헤더 : {"alg":"HS512","typ" : "JWT","kid" : "e2e3d6d3-2742-4aab-b986-6d56d39095d1"}
+  refresh_token 페이로드(앞부분):
+    {"exp":1788500446,"iat":1788498646,"jti":"54096fa4-edc6-bf6d-a88c-d2a6138bc6ee","iss":"https://auth.hyeonworks.com/realms/keycloak-patterns"
+  access_token 헤더  : {"alg":"RS256","typ" : "JWT","kid" : "OY-caYDNGoP4HMAz-Q9UPTU-DM1i896NuzUZu6gfCqM"}
+
+  → bytea 에 들어 있는 것은 암호화된 덩어리가 아니라 JWT 문자열 그대로다.
+    DB 읽기 권한만 있으면 그 자리에서 쓸 수 있는 토큰을 얻는다.

docs/evidence/b2-multi-instance-session/04-overwrite-test.txt

@@ -0,0 +1,25 @@
+=== [현재] 같은 사용자의 항목 ===
+ client_registration_id | principal_name |   access_token_issued_at   |              at_md5              
+------------------------+----------------+----------------------------+----------------------------------
+ keycloak               | labuser        | 2026-09-04 05:10:46.927192 | 675af2286bfc2fd9d2bab7bc8f391df7
+(1 row)
+
+  행 수: 1
+
+=== [모의 두 번째 브라우저] 세션만 지우고 같은 사용자로 다시 로그인시킨다 ===
+  (브라우저가 달라도 principal 은 같으므로 조회 키가 같다)
+  Redis 세션 삭제 완료 — 다음 요청이 새 로그인을 만든다
+=== [재로그인 후] 행이 늘었는가, 덮어써졌는가 ===
+ client_registration_id | principal_name |   access_token_issued_at   |              at_md5              
+------------------------+----------------+----------------------------+----------------------------------
+ keycloak               | labuser        | 2026-09-04 05:12:13.018828 | e19a63fc5aa18bd0a68b3e19dff16b3b
+(1 row)
+
+  행 수: 1
+
+  ★ 행 수가 1 그대로이고 md5 가 바뀌었으면 → 덮어쓰기다
+
+=== Q1 검증 ④ — 로그아웃하면 두 저장소가 다 정리되는가 ===
+  로그아웃 전
+    Redis: 1 키
+    PostgreSQL: 1 행

docs/evidence/b2-multi-instance-session/05-logout-cleanup.txt

@@ -0,0 +1,14 @@
+=== Q1 검증 ④ — 로그아웃 후 두 저장소 상태 ===
+  Redis 세션      : 0 키
+  PostgreSQL 토큰 : 1 행
+
+ principal_name |   access_token_issued_at   |  access_token_expires_at   
+----------------+----------------------------+----------------------------
+ labuser        | 2026-09-04 05:12:13.018828 | 2026-09-04 05:13:13.018828
+(1 row)
+
+
+  ★ Redis 는 비었는데 PostgreSQL 에 행이 남아 있으면 → 한쪽만 정리된 것
+
+=== Keycloak 쪽 SSO 세션은? ===
+  Keycloak 온라인 세션: 2

docs/evidence/b2-multi-instance-session/README.md

@@ -0,0 +1,21 @@
+# B-2 — 다중 인스턴스 운영 증거
+
+2026-09-04 15:05–15:15 KST
+해설: [`docs/experiment-b2-multi-instance-session.md`](../../experiment-b2-multi-instance-session.md)
+
+| 파일 | 무엇을 보여주는가 |
+|---|---|
+| `01-jdbc-store-deploy.txt` | JDBC 저장소로 배포. **테이블이 조용히 안 만들어졌다** |
+| `02-schema.txt` | 원인 — 기본 DDL 은 `blob`(PostgreSQL 에 없음), `-postgres.sql` 판본이 따로 있다. **`PRIMARY KEY (client_registration_id, principal_name)`** — 조회 키 문제가 DDL 에 박혀 있다 |
+| `03-plaintext-tokens.txt` | **Q3 검증 2번** — `bytea` 안이 JWT 문자열 그대로. 디코드하면 `{"alg":"HS512",...}` |
+| `04-overwrite-test.txt` | **Q1 검증 3번** — 같은 사용자 재로그인 시 행 수 1 그대로, `issued_at` 과 md5 만 바뀜 = **UPDATE(덮어쓰기)** |
+| `05-logout-cleanup.txt` | **Q1 검증 4번** — Redis 0키 / PostgreSQL **1행 잔존** / Keycloak SSO **2세션 잔존** |
+| `b2-before-relogin.png` | JDBC 전환 직후, 옛 세션은 여전히 `false` |
+| `b2-tokens-shared-across-instances.png` | 재로그인 후 **`accessTokenStoredOnServer: true`** — 두 replica 에서 동작 |
+
+## 핵심 네 줄
+
+1. **세션 Redis + 토큰 PostgreSQL 분리 저장이 성립한다.** B-1 의 "로그인은 됐는데 토큰이 없는" 상태가 해결됐다.
+2. **refresh token 은 평문이다.** DB 읽기 권한이면 작동하는 토큰을 얻는다.
+3. **같은 사용자의 두 번째 로그인이 첫 번째를 덮어쓴다.** 기본키에 session id 가 없어 구조적으로 그렇다.
+4. **로그아웃은 셋 중 하나만 지운다.** 평문 토큰과 Keycloak SSO 세션이 남는다.

docs/evidence/b3-refresh-contention/01-concurrent-refresh.txt

@@ -0,0 +1,11 @@
+=== [1] refresh token 하나 확보 ===
+  토큰 길이: 811
+  jti: 8e7e3ee2-0dc8-573d-58ec-d12651a50b9c
+  sid: BvFiB01Rntz1FcLdf7zG4BNt
+
+=== [2] 같은 refresh token 으로 동시에 5회 갱신 ===
+  요청 1: HTTP 400  {"error":"invalid_grant","error_description":"Maximum allowed refresh token reuse exceeded"}
+  요청 2: HTTP 400  {"error":"invalid_grant","error_description":"Session doesn't have required client"}
+  요청 3: HTTP 400  {"error":"invalid_grant","error_description":"Session doesn't have required client"}
+  요청 4: HTTP 400  {"error":"invalid_grant","error_description":"Session doesn't have required client"}
+  요청 5: HTTP 200  {"access_token":"...(발급됨)

docs/evidence/b3-refresh-contention/02-session-impact.txt

@@ -0,0 +1,16 @@
+=== [3] 이긴 요청이 받은 새 토큰은 쓸 수 있는가 ===
+  새 refresh token 길이: 810
+  그 토큰으로 다시 갱신:  HTTP 400
+    {"error":"invalid_grant","error_description":"Session doesn't have required client"}
+
+=== [4] 그 sid 의 세션이 DB 에 남아 있는가 ===
+     user_session_id      | offline_flag | last_session_refresh 
+--------------------------+--------------+----------------------
+ BvFiB01Rntz1FcLdf7zG4BNt | 0            |           1788498996
+(1 row)
+
+=== [5] revoked_token 테이블 ===
+ revoked_count 
+---------------
+             0
+(1 row)

docs/evidence/b3-refresh-contention/03-client-session-removed.txt

@@ -0,0 +1,14 @@
+=== user session 과 client session 을 나눠서 본다 ===
+     user_session_id      | offline_flag | client_sessions 
+--------------------------+--------------+-----------------
+ BvFiB01Rntz1FcLdf7zG4BNt | 0            |               0
+(1 row)
+
+
+=== 대조: 정상 세션 하나를 새로 만들어 비교 ===
+  새 sid: JT-XuepgutWcE273QwAnIXta
+     user_session_id      | client_sessions 
+--------------------------+-----------------
+ JT-XuepgutWcE273QwAnIXta |               1
+(1 row)
+

docs/evidence/b3-refresh-contention/04-policy-comparison.txt

@@ -0,0 +1,24 @@
+=== 구성 A: rotation ON (revokeRefreshToken=true, maxReuse=0) — 앞서 측정 ===
+    성공 1 / 5, 세션 파괴됨
+
+=== 구성 B: rotation OFF (revokeRefreshToken=false) ===
+    sid=iW1CGyO7COdyJLryIrCt3njk
+    1: 200 
+    2: 200 
+    3: 200 
+    4: 200 
+    5: 200 
+    성공 5 / 5
+    이긴 토큰 재사용: HTTP 200
+    남은 client_session: 1
+
+=== 구성 C: rotation ON + 재사용 1회 허용 (maxReuse=1) ===
+    sid=72c04JCdr0NpCHGQmXWW2wM8
+    1: 200 
+    2: 400 "error_description":"Session doesn't have required client"
+    3: 200 
+    4: 400 "error_description":"Maximum allowed refresh token reuse exceeded"
+    5: 400 "error_description":"Session doesn't have required client"
+    성공 2 / 5
+    이긴 토큰 재사용: HTTP 400
+    남은 client_session: 0

docs/evidence/b3-refresh-contention/README.md

@@ -0,0 +1,18 @@
+# B-3 — Refresh Token 동시 갱신 경쟁 증거
+
+2026-09-04 15:15–15:25 KST
+해설: [`docs/experiment-b3-refresh-token-contention.md`](../../experiment-b3-refresh-token-contention.md)
+
+| 파일 | 무엇을 보여주는가 |
+|---|---|
+| `01-concurrent-refresh.txt` | 같은 토큰으로 동시 5회 — **1개만 200**, 나머지는 `Maximum allowed refresh token reuse exceeded` 와 `Session doesn't have required client` **두 종류** 오류 |
+| `02-session-impact.txt` | **★ 이긴 요청의 새 토큰조차 400.** user_session 행은 남아 있고 `revoked_token` 은 0건 |
+| `03-client-session-removed.txt` | **기제 확정 (대조군 포함)** — 경쟁 세션 `client_sessions=0`, 정상 세션 `client_sessions=1` |
+| `04-policy-comparison.txt` | 정책 3종 비교 — rotation OFF 는 **5/5 성공·세션 생존**, maxReuse=1 은 **여전히 세션 파괴** |
+
+## 핵심 네 줄
+
+1. **"하나는 성공"이 아니다.** 이긴 요청이 받은 토큰도 곧바로 쓸 수 없다.
+2. **재사용 탐지가 client session 을 제거한다.** user session 은 껍데기로 남아 `Session doesn't have required client` 가 된다.
+3. **`refreshTokenMaxReuse` 를 올려도 안 된다.** 동시 요청 수만큼 올려야 하고 그러면 rotation 의 목적이 사라진다.
+4. **재시도로 회복되지 않으므로 Q2 의 답은 lock 이다.** 그리고 lock 은 저장소 쪽(가급적 DB 행 잠금)에 있어야 한다.

docs/experiment-b1-redis-session-store.md

@@ -0,0 +1,297 @@
+# B-1 — Redis 를 붙이면 무엇이 옮겨지고 무엇이 안 옮겨지는가 → Q3
+
+브랜치 `feature/keycloak-b1-redis-session-store` ·
+증거 [`docs/evidence/b1-redis-session-store/`](evidence/b1-redis-session-store/) ·
+2026-09-04 14:50–15:05 KST
+
+선행: [`B-0`](experiment-b0-bff-redis-deploy.md)
+
+**대응 질문** — [Q3 · BFF의 Session과 OAuth2AuthorizedClient를 어디에 저장할 것인가](https://hyeonworks.com/questions/bff-session-authorized-client-store)
+
+---
+
+## 0. 결론부터
+
+| | before | after | |
+|---|---|---|---|
+| `sessionRepository` | (없음, Tomcat 기본) | **`RedisSessionRepository`** | **옮겨졌다** |
+| `authorizedClientService` | `InMemoryOAuth2AuthorizedClientService` | **`InMemoryOAuth2AuthorizedClientService`** | **그대로다** |
+| `authorizedClientRepository` | `AuthenticatedPrincipalOAuth2AuthorizedClientRepository` | **동일** | **그대로다** |
+
+그 결과 사용자에게는 이렇게 보인다.
+
+```json
+{"principal":"labuser",                     ← 로그인은 되어 있다
+ "accessTokenStoredOnServer":false,         ← 그런데 토큰이 없다
+ "refreshTokenStoredOnServer":false,
+ "browserTokenCount":0}
+```
+
+**"로그인은 되어 있는데 아무것도 못 하는" 상태**가 만들어진다.
+Q1 이 *"Session Store 를 공유 저장소로 변경하는 것만으로는 충분하지 않다"* 고
+쓴 것의 실물이다.
+
+---
+
+## 1. 문제 ① — 쿠버네티스가 내 환경변수를 덮어썼다
+
+배포하자마자 파드가 안 떴다.
+
+```
+Failed to bind properties under 'spring.data.redis.port' to int:
+    Property: spring.data.redis.port
+    Value: "${REDIS_PORT:6379}"
+    Reason: failed to convert java.lang.String to int
+            (caused by NumberFormatException: For input string: "tcp://10.43.57.116:6379")
+```
+
+**쿠버네티스가 `REDIS_PORT=tcp://10.43.57.116:6379` 를 주입했다.**
+
+### 개념 — Service Links
+
+쿠버네티스는 같은 네임스페이스의 **모든 Service 마다** Docker link 시절의
+환경변수를 파드에 자동으로 넣는다.
+
+```
+   Service 이름이 redis 이면
+     REDIS_SERVICE_HOST=10.43.57.116
+     REDIS_SERVICE_PORT=6379
+     REDIS_PORT=tcp://10.43.57.116:6379        ← 이게 문제
+     REDIS_PORT_6379_TCP=tcp://10.43.57.116:6379
+     REDIS_PORT_6379_TCP_ADDR=10.43.57.116
+     ...
+```
+
+**`<SVCNAME>_PORT` 는 포트 번호가 아니라 URL 형태다.** 이름이 겹치면
+애플리케이션 설정이 조용히 오염된다.
+
+```yaml
+spec:
+  enableServiceLinks: false      # 근본 처방
+```
+
+> **환경변수 이름을 바꿔 피할 수도 있다.** 그러면 다음 사람이 같은 함정에
+> 다시 빠진다. **주입 자체를 끄는 쪽**을 골랐다.
+>
+> 이 함정은 Service 이름과 환경변수 이름이 겹칠 때만 나타나므로,
+> `REDIS`, `POSTGRES`, `MYSQL` 처럼 **흔한 이름일수록 위험하다.**
+
+## 문제 ② — 테스트가 Redis 를 찾다가 죽었다
+
+`spring-session-data-redis` 를 넣으면 컨텍스트 기동 시 Redis 에 붙으려 한다.
+테스트에는 Redis 가 없다.
+
+```java
+@SpringBootTest(properties = {
+    "KEYCLOAK_CLIENT_SECRET=test-only-secret",
+    // 테스트는 Redis 를 띄우지 않는다
+    "spring.session.store-type=none",
+})
+```
+
+## 문제 ③ — 리소스 서버가 아예 없었다
+
+API 호출이 `500` 이었다. 원인은 토큰이 아니었다.
+
+```
+java.nio.channels.UnresolvedAddressException
+```
+
+`RESOURCE_API_BASE_URL=http://echo.keycloak-lab.svc:8080` 인데 `echo` 는
+**`header-lab` 네임스페이스의 8081** 이었다. 배포조차 되어 있지 않았다.
+
+> **500 을 보고 "토큰이 없어서"라고 읽을 뻔했다.** 로그를 보니 DNS 였다.
+> A층에서 반복해서 배운 것 — **증상과 원인을 붙이기 전에 로그를 본다.**
+
+```yaml
+# 다른 네임스페이스의 서비스는 <svc>.<ns>.svc 로 부른다
+value: http://echo.header-lab.svc:8081
+```
+
+---
+
+## 2. 자동구성이 실제로 바뀌었는가 — B-0 의 방법을 다시 쓴다
+
+```bash
+kubectl -n keycloak-lab exec <bff-pod> -- wget -qO- http://localhost:8083/actuator/beans
+```
+
+```
+  빈 수: 321 → 402  (+81)
+
+  --- 세션 저장소 (새로 생긴 것) ---
+    ★ sessionRepository                    -> RedisSessionRepository
+    ★ springSessionRepositoryFilter        -> SessionRepositoryFilter
+    ★ RedisHttpSessionConfiguration
+    ★ cookieSerializer                     -> DefaultCookieSerializer
+
+  --- OAuth2 authorized client ---
+    authorizedClientService
+      before: InMemoryOAuth2AuthorizedClientService
+      after : InMemoryOAuth2AuthorizedClientService    그대로 — Redis 로 안 옮겨졌다
+    authorizedClientRepository
+      before: AuthenticatedPrincipalOAuth2AuthorizedClientRepository
+      after : AuthenticatedPrincipalOAuth2AuthorizedClientRepository   그대로
+```
+
+**빈 81개가 늘었는데 authorized client 는 하나도 안 바뀌었다.**
+
+> **"Redis 를 붙였다"가 "상태가 공유된다"를 뜻하지 않는다.**
+> 무엇이 옮겨졌는지 **찍어서 확인**해야 한다. B-0 을 실험으로 만든 이유다.
+
+---
+
+## 3. Redis 안에 무엇이 들어갔는가 → Q3 검증 2번
+
+```
+=== Redis 키 ===
+bff:session:sessions:8963b6de-3564-4775-9ccd-1ee9616b83ae
+  dbsize: 1
+
+=== 필드 ===
+  sessionAttr:SPRING_SECURITY_CONTEXT
+  sessionAttr:SPRING_SECURITY_SAVED_REQUEST
+  sessionAttr:SPRING_SECURITY_LAST_EXCEPTION
+  sessionAttr:...HttpSessionOAuth2AuthorizationRequestRepository.AUTHORIZATION_REQUEST
+  lastAccessedTime / maxInactiveInterval / creationTime
+
+=== TTL ===
+  1772 초        ← spring.session.timeout=30m 과 일치
+```
+
+### **refresh token 은 Redis 에 없다**
+
+Q3 는 *"저장소를 직접 열어 refresh token 이 평문으로 남는지 확인한다"* 를
+검증 항목으로 두었다. 답은 더 앞에 있었다 — **애초에 들어가지 않는다.**
+
+```
+   Application Session  ──▶ Redis        (인증 상태, principal, 인가 요청)
+   OAuth2AuthorizedClient ─▶ 프로세스 메모리  (access token, refresh token)
+```
+
+**"토큰 암호화를 어떻게 할까"를 고민하기 전에, 토큰이 그 저장소에 가지도
+않는다는 것을 먼저 알아야 한다.**
+
+### 직렬화는 Java 네이티브다
+
+```
+\xac\xed\x00\x05sr\x00=org.springframework.security.core.context.SecurityContextImpl
+```
+
+`\xac\xed` 는 **Java 직렬화 매직 넘버**다. JSON 이 아니다.
+
+| 결과 | |
+|---|---|
+| 사람이 못 읽는다 | 운영 중 디버깅이 어렵다 |
+| **클래스 버전에 묶인다** | 애플리케이션을 올리면 **기존 세션이 역직렬화에 실패**할 수 있다 |
+| 역직렬화 취약점 | 신뢰할 수 없는 데이터가 들어오면 위험한 형식이다 |
+
+**D-2(버전 업그레이드)에서 이것이 다시 나온다** — Spring Security 버전이
+바뀌면 Redis 에 남은 세션이 깨질 수 있다.
+
+---
+
+## 4. 사용자에게 보이는 결과 — 가장 중요한 부분
+
+![Redis 전환 후 token-boundary](evidence/b1-redis-session-store/b1-token-boundary-after-redis.png)
+
+```json
+{"pattern":"AP3-backend-for-frontend",
+ "principal":"labuser",                  ← 세션은 Redis 에서 복원되었다
+ "accessTokenStoredOnServer":false,      ← 토큰은 사라졌다
+ "refreshTokenStoredOnServer":false,
+ "browserTokenCount":0,
+ "csrfProtectionEnabled":true}
+```
+
+**파드가 전부 교체됐는데 로그인 상태는 살아남았다.** Redis 덕분이다.
+**그런데 토큰은 같이 살아남지 못했다.** 인스턴스 메모리에 있었으니까.
+
+```
+   사용자 관점:  로그인되어 있다고 나온다
+   실제:        BFF 가 사용자를 대신해 아무것도 못 한다
+```
+
+**이것이 "부분적으로만 공유했을 때"의 실패 모양이다.**
+완전히 로그아웃되는 편이 차라리 낫다 — 적어도 사용자가 다시 로그인한다.
+
+### B-0 과 나란히 놓으면
+
+| | B-0 (Redis 없음, replica 1) | **B-1 (Redis 세션, replica 2)** |
+|---|---|---|
+| `principal` | labuser | labuser |
+| `accessTokenStoredOnServer` | **true** | **false** |
+| 파드 재시작 후 | 로그아웃 | **로그인 상태만 남고 토큰은 소실** |
+
+---
+
+## 5. Q3 검증 항목 대조
+
+| # | Q3 의 검증 | 결과 |
+|---|---|---|
+| 1 | 인스턴스 두 대에서 로그인 유지·재시작 복구 | **세션은 유지, 토큰은 소실** |
+| 2 | 저장소를 열어 refresh token 이 평문인지 | **평문 이전에 존재하지 않는다** |
+| 3 | session TTL 과 token 만료 어긋남 | TTL 1772초 관측. 토큰 만료(60초)와 **처음부터 어긋나 있다** |
+| 4 | logout 뒤 두 store 잔여 항목 | **B-2 에서 이어서** |
+| 5 | 저장소를 끊었을 때 오류 | **B-5 에서** |
+| 6 | 같은 store vs 분리 | **분리가 기본값이었다** — 고르는 것이 아니라 이미 그렇다 |
+| 7 | 저장소 지연이 화면 지연으로 | **B-2 이후** |
+
+**6번의 답이 이 실험의 요지다.** "두 상태를 같은 저장소에 둘지 나눌지"는
+선택지가 아니라 **이미 나뉘어 있고, 나뉜 채로 두면 깨진다.**
+
+---
+
+## 6. 그래서 무엇을 해야 하는가
+
+`OAuth2AuthorizedClientService` 를 공유 저장소로 옮기는 구현이 따로 필요하다.
+
+| 후보 | |
+|---|---|
+| `JdbcOAuth2AuthorizedClientService` | Spring Security 기본 제공. **PostgreSQL 이 이미 있다** |
+| 직접 구현 (Redis) | `OAuth2AuthorizedClientService` 인터페이스를 Redis 로 구현 |
+| 세션 안에 넣기 | `HttpSessionOAuth2AuthorizedClientRepository` 를 쓰면 세션과 함께 Redis 로 간다 |
+
+**세 번째가 흥미롭다** — 조회 키 문제(principal 기준)까지 같이 해결된다.
+세션 단위로 저장되므로 **같은 사용자의 다른 브라우저가 서로를 덮어쓰지 않는다.**
+대신 세션이 커진다.
+
+**B-2 에서 이 선택지를 비교한다.**
+
+---
+
+## 7. 재현 절차 (명령어)
+
+```bash
+# 1. 의존성 두 개를 함께 넣는다 (하나만 넣으면 조용히 in-memory 로 남는다)
+#    spring-session-data-redis  +  spring-boot-starter-data-redis
+
+# 2. 테스트는 Redis 를 안 띄우므로 store-type=none 을 준다
+
+# 3. 배포 — enableServiceLinks: false 를 잊지 말 것
+kubectl apply -f deploy/lab/k8s/bff-redis.yaml
+
+# 4. 자동구성이 실제로 바뀌었는지 확인 (B-0 의 방법)
+kubectl -n keycloak-lab exec <bff-pod> -- wget -qO- http://localhost:8083/actuator/beans > after.json
+#    sessionRepository 가 RedisSessionRepository 인가
+#    authorizedClientService 는 여전히 InMemory 인가   ← 이쪽이 핵심
+
+# 5. Redis 를 직접 연다
+kubectl -n keycloak-lab exec deploy/redis -- redis-cli --scan
+kubectl -n keycloak-lab exec deploy/redis -- redis-cli hkeys "bff:session:sessions:<id>"
+kubectl -n keycloak-lab exec deploy/redis -- redis-cli ttl  "bff:session:sessions:<id>"
+
+# 6. 사용자 관점 확인
+#    브라우저로 https://app1.hyeonworks.com/bff/token-boundary
+```
+
+---
+
+## 8. 다음 실험에 남기는 것
+
+| 실험 | 이 실험이 준 것 |
+|---|---|
+| **B-2** 다중 인스턴스 | **authorized client 를 어디로 옮길지**가 남았다. 세 후보를 비교한다 |
+| **B-3** refresh 경쟁 | 토큰이 공유되어야 경쟁이 재현된다 — **아직 공유되지 않았다** |
+| **D-2** 업그레이드 | **Java 직렬화된 세션**이 버전 변경에 견디는가 |
+| 운영 | `enableServiceLinks: false` — Service 이름과 환경변수 충돌 |

docs/experiment-b2-multi-instance-session.md

@@ -0,0 +1,314 @@
+# B-2 — 인스턴스를 늘렸을 때 무엇이 깨지고 무엇이 남는가 → Q1
+
+브랜치 `feature/keycloak-b2-multi-instance-session` ·
+증거 [`docs/evidence/b2-multi-instance-session/`](evidence/b2-multi-instance-session/) ·
+2026-09-04 15:05–15:15 KST
+
+선행: [`B-0`](experiment-b0-bff-redis-deploy.md) · [`B-1`](experiment-b1-redis-session-store.md)
+
+**대응 질문** — [Q1 · 서버 세션 기반 인증 구조는 다중 인스턴스에서 어떻게 운영할 것인가](https://hyeonworks.com/questions/server-session-pattern-multi-instance)
+
+---
+
+## 0. 결론부터
+
+B-1 이 남긴 문제(세션만 공유되고 토큰은 안 됨)를 **JDBC 로 옮겨 해결했다.**
+그러자 **다른 두 문제가 남았다.**
+
+| Q1 검증 | 결과 |
+|---|---|
+| ① 다른 인스턴스로 요청해도 되는가 | **된다** — 세션 Redis + 토큰 PostgreSQL |
+| ② 재시작 후 로그인 유지 | **된다** |
+| ③ 같은 사용자의 다른 브라우저가 덮어쓰는가 | **★ 덮어쓴다.** 기본키가 그렇게 되어 있다 |
+| ④ 로그아웃하면 두 저장소가 다 정리되는가 | **★ 아니다. 한쪽만 정리된다** |
+
+```
+로그아웃 후:
+  Redis 세션      : 0 키    ← 정리됨
+  PostgreSQL 토큰 : 1 행    ← 평문 refresh token 이 그대로 남는다
+  Keycloak SSO    : 2 세션  ← 남아 있다
+```
+
+---
+
+## 1. 설계 — 왜 JDBC 를 골랐나
+
+B-1 에서 컨트롤러가 `OAuth2AuthorizedClientService` 를 직접 쓰는 것을 확인했다.
+
+```java
+private final OAuth2AuthorizedClientService authorizedClientService;
+...
+OAuth2AuthorizedClient client = authorizedClientService.loadAuthorizedClient(...);
+```
+
+| 후보 | 컨트롤러 변경 | 조회 키 문제 |
+|---|---|---|
+| **`JdbcOAuth2AuthorizedClientService`** | **불필요** (같은 인터페이스) | 안 고쳐짐 |
+| Redis 직접 구현 | 불필요 | 안 고쳐짐 |
+| `HttpSessionOAuth2AuthorizedClientRepository` | **필요** (Repository 로 바꿔야) | **고쳐짐** |
+
+**Q3 가 "Redis 와 JDBC 중 무엇" 을 물었으므로 JDBC 를 골랐다.**
+PostgreSQL 이 이미 있어 새 인프라가 필요 없고, 세션(Redis) + 토큰(JDBC)
+**분리 저장**을 그대로 시험할 수 있다.
+
+```java
+@Bean
+OAuth2AuthorizedClientService authorizedClientService(
+    JdbcOperations jdbcOperations,
+    ClientRegistrationRepository clientRegistrationRepository
+) {
+    return new JdbcOAuth2AuthorizedClientService(jdbcOperations, clientRegistrationRepository);
+}
+```
+
+---
+
+## 2. 문제 — 스키마가 조용히 안 만들어졌다
+
+파드는 떴고 Hikari 도 붙었는데 테이블이 없었다.
+
+```
+HikariPool-1 - Start completed.
+...
+Did not find any relation named "oauth2_authorized_client".
+```
+
+**Spring Security 가 두 벌의 DDL 을 제공한다.**
+
+```
+org/springframework/security/oauth2/client/oauth2-client-schema.sql            ← 기본
+org/springframework/security/oauth2/client/oauth2-client-schema-postgres.sql   ← PostgreSQL 용
+```
+
+기본 판본은 `blob` 타입을 쓴다. **PostgreSQL 에는 그 타입이 없다** (`bytea` 다).
+
+```sql
+access_token_value blob NOT NULL,      -- 기본 판본
+access_token_value bytea NOT NULL,     -- postgres 판본
+```
+
+그리고 내가 `continue-on-error: true` 를 켜둬서 **그 실패가 삼켜졌다.**
+
+```yaml
+schema-locations: classpath:org/springframework/security/oauth2/client/oauth2-client-schema-postgres.sql
+```
+
+> **`continue-on-error` 는 "없어도 되는 초기화"에만 쓴다.**
+> 여기서는 그것 때문에 "테이블이 조용히 안 생기는" 상태가 됐고, 파드는
+> **정상으로 보였다.** A층에서 반복해서 만난 "실패가 조용한" 유형이다.
+
+### 그리고 DDL 자체가 Q1 의 답을 담고 있었다
+
+```sql
+CREATE TABLE oauth2_authorized_client (
+  client_registration_id varchar(100) NOT NULL,
+  principal_name         varchar(200) NOT NULL,
+  ...
+  PRIMARY KEY (client_registration_id, principal_name)
+);
+```
+
+**기본키에 session id 가 없다.** B-0 에서 빈 이름
+(`AuthenticatedPrincipalOAuth2AuthorizedClientRepository`)으로 짐작한 것이
+**테이블 정의로 확정된다.** 구현을 바꿔도, 저장소를 바꿔도, **이 키를 그대로
+쓰는 한 같은 사용자의 두 브라우저는 한 행을 공유한다.**
+
+---
+
+## 3. 결과 ① — 인스턴스 간 공유가 된다
+
+```
+=== 재로그인 후 oauth2_authorized_client ===
+ client_registration_id | principal_name | access_token_type | at_len | rt_len
+------------------------+----------------+-------------------+--------+--------
+ keycloak               | labuser        | Bearer            |   1431 |    744
+
+=== Redis ===
+ bff:session:sessions:c63c39ee-...   (dbsize 1)
+```
+
+![토큰이 인스턴스 간에 공유된다](evidence/b2-multi-instance-session/b2-tokens-shared-across-instances.png)
+
+```json
+{"principal":"labuser",
+ "accessTokenStoredOnServer":true,      ← B-1 에서는 false 였다
+ "refreshTokenStoredOnServer":true,
+ "browserTokenCount":0}
+```
+
+**두 저장소가 각자 제 일을 한다.**
+
+```
+   Application Session ──▶ Redis        (인증 상태)
+   OAuth2AuthorizedClient ▶ PostgreSQL  (access / refresh token)
+```
+
+**Q3 가 "두 상태를 반드시 같은 저장소에 보관해야 하는 것은 아니다" 라고 한 것이
+실물로 성립한다.** 다만 B-1 에서 본 대로, **한쪽만 옮기면 더 나쁘다.**
+
+---
+
+## 4. 결과 ② — refresh token 이 평문이다 → Q3 검증 2번
+
+```sql
+select convert_from(refresh_token_value, 'UTF8') from oauth2_authorized_client;
+```
+
+```
+eyJhbGciOiJIUzUxMiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJlMmUz...
+```
+
+디코드하면
+
+```
+refresh_token 헤더 : {"alg":"HS512","typ":"JWT","kid":"e2e3d6d3-..."}
+refresh_token 본문 : {"exp":1788500446,"iat":1788498646,"jti":"54096fa4-...",
+                     "iss":"https://auth.hyeonworks.com/realms/keycloak-patterns"}
+access_token 헤더  : {"alg":"RS256","typ":"JWT","kid":"OY-caYDNGoP4HMAz-..."}
+```
+
+**`bytea` 안에 든 것은 암호화된 덩어리가 아니라 JWT 문자열 그대로다.**
+
+> **DB 읽기 권한만 있으면 그 자리에서 쓸 수 있는 토큰을 얻는다.**
+> 백업 파일, 읽기 전용 복제본, 덤프, 로그 — 어디로든 새면 그대로 쓸 수 있다.
+>
+> Q3 의 가정 *"저장된 refresh token 을 평문으로 두면 안 된다"* 는 옳고,
+> **Spring Security 기본 구현은 그 가정을 지키지 않는다.**
+> 암호화하려면 `JdbcOAuth2AuthorizedClientService` 를 감싸거나 직접 구현해야 한다.
+
+---
+
+## 5. 결과 ③ — 같은 사용자의 두 번째 로그인이 덮어쓴다 → Q1 검증 3번
+
+같은 사용자로 다시 로그인시키고 행을 비교했다.
+
+```
+=== 재로그인 전 ===
+ principal_name | access_token_issued_at     | at_md5
+ labuser        | 2026-09-04 05:10:46.927192 | 675af2286bfc2fd9d2bab7bc8f391df7
+  행 수: 1
+
+=== 재로그인 후 ===
+ labuser        | 2026-09-04 05:12:13.018828 | e19a63fc5aa18bd0a68b3e19dff16b3b
+  행 수: 1
+```
+
+**행 수는 그대로, 값만 바뀌었다. UPDATE 다.**
+
+```
+   브라우저 A 로그인  →  (keycloak, labuser) 행 생성
+   브라우저 B 로그인  →  같은 행을 덮어쓴다
+                          └─ A 의 토큰은 사라진다
+```
+
+**A 쪽에서 다음 요청을 하면 B 의 토큰을 쓰게 된다.** 같은 사용자이므로
+당장은 문제가 안 보이지만,
+
+| 언제 문제가 되는가 | |
+|---|---|
+| B 가 로그아웃하면 | **A 도 같이 끊긴다** (행이 지워지므로) |
+| refresh 회전이 걸려 있으면 | **A 와 B 가 같은 refresh token 을 다툰다** → B-3 |
+| 스코프가 다른 로그인이면 | 나중 것이 이긴다 |
+
+**저장소를 바꿔도 안 고쳐진다.** 고치려면 조회 키에 session 을 넣어야 하고,
+그것이 `HttpSessionOAuth2AuthorizedClientRepository` 다.
+
+---
+
+## 6. 결과 ④ — 로그아웃이 한쪽만 정리한다 → Q1 검증 4번
+
+```
+=== 로그아웃 후 ===
+  Redis 세션      : 0 키    ← 정리됨
+  PostgreSQL 토큰 : 1 행    ← 남아 있다
+  Keycloak SSO    : 2 세션  ← 남아 있다
+
+ principal_name | access_token_issued_at     | access_token_expires_at
+ labuser        | 2026-09-04 05:12:13.018828 | 2026-09-04 05:13:13.018828
+```
+
+**세 저장소 중 하나만 지워졌다.**
+
+```
+   로그아웃
+     ├─▶ HttpSession 무효화        ✔ Redis 키 삭제됨
+     ├─▶ authorized client 삭제    ✗ 아무도 안 지운다
+     └─▶ Keycloak SSO 종료         ✗ RP-initiated logout 을 안 보낸다
+```
+
+| 남은 것 | 결과 |
+|---|---|
+| **PostgreSQL 의 평문 refresh token** | 로그아웃한 사용자의 **작동하는 토큰**이 DB 에 남는다 |
+| **Keycloak SSO 세션** | 앱을 다시 열면 **로그인 화면 없이 다시 로그인**된다 |
+
+**두 번째가 사용자에게 특히 혼란스럽다** — "로그아웃했는데 다시 들어가면
+그냥 들어가진다". 실험 중에도 계속 그랬다. 세션을 지워도 Keycloak SSO 가
+살아 있어 조용히 재인증됐다.
+
+### 무엇을 해야 하는가
+
+| 필요한 것 | 방법 |
+|---|---|
+| authorized client 삭제 | `LogoutSuccessHandler` 에서 `removeAuthorizedClient` 호출 |
+| Keycloak 세션 종료 | **RP-initiated logout** — `OidcClientInitiatedLogoutSuccessHandler` |
+| 두 곳을 원자적으로 | 한쪽이 실패하면? — **정리 순서와 실패 처리를 정해야 한다** |
+
+**Q3 의 미지수 5번("두 store 를 logout 에서 어떻게 한 번에 지우게 되는가")이
+바로 이 지점이며, 답은 "지금은 하나도 안 지운다" 이다.**
+
+---
+
+## 7. Q1 검증 항목 대조
+
+| # | Q1 의 검증 | 결과 |
+|---|---|---|
+| 1 | 다른 인스턴스로 요청 시 200 유지 | **된다** (Redis + JDBC 조합) |
+| 2 | 재시작 후 session cookie 로 상태 유지 | **된다** |
+| 3 | 두 브라우저에서 authorized client 덮어쓰기 | **★ 덮어쓴다.** 기본키가 원인 |
+| 4 | 한쪽 logout 후 다른 쪽 | **★ 한쪽만 정리된다** |
+| 5 | session 만료 ≠ token 만료 | 세션 30분 / access 60초 — **처음부터 어긋나 있다** |
+| — | (B-0 에서) replica 2개에서 **로그인 자체가 실패** | Redis 세션으로 **해결됨** |
+
+---
+
+## 8. 재현 절차 (명령어)
+
+```bash
+# 1. JDBC authorized client service 빈 추가 (SecurityConfig)
+#    + spring-boot-starter-jdbc, postgresql 의존성
+
+# 2. 스키마 — PostgreSQL 판본을 써야 한다
+kubectl -n keycloak-lab exec <bff-pod> -- sh -c \
+  'unzip -p /app/app.jar BOOT-INF/lib/spring-security-oauth2-client-*.jar' > /dev/null
+#   실제로는 nested jar 를 풀어서 -postgres.sql 을 꺼낸다
+kubectl -n keycloak-lab exec -i deploy/postgres -- psql -U keycloak -d keycloak < oauth2-pg.sql
+
+# 3. 저장소가 채워지는지
+kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
+  -c "select client_registration_id, principal_name, length(refresh_token_value) from oauth2_authorized_client"
+
+# 4. 평문 여부
+kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -tAc \
+  "select convert_from(refresh_token_value,'UTF8') from oauth2_authorized_client limit 1"
+
+# 5. 덮어쓰기 — 같은 사용자로 다시 로그인시키고 md5 를 비교
+kubectl -n keycloak-lab exec deploy/redis -- redis-cli flushall     # 세션만 지운다
+#   브라우저로 재접속 → 행 수는 그대로, md5 는 바뀐다
+
+# 6. 로그아웃 정리
+#    POST /logout (CSRF 는 form 파라미터 _csrf 로)
+kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize
+kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak \
+  -tAc "select count(*) from oauth2_authorized_client"
+```
+
+---
+
+## 9. 다음 실험에 남기는 것
+
+| 실험 | 이 실험이 준 것 |
+|---|---|
+| **B-3** refresh 경쟁 | **이제 토큰이 공유된다** — 경쟁이 재현될 조건이 갖춰졌다. 그리고 **덮어쓰기 때문에 두 브라우저가 같은 refresh token 을 다툰다** |
+| **B-4** Edge 인가 | 리소스 서버 직접 호출 차단(Q1 제약)은 2홉 NetworkPolicy 패턴 재사용 |
+| **B-5** Redis 상실 | 이제 세션(Redis)과 토큰(PostgreSQL)이 나뉘어 있어 **각각 죽여볼 수 있다** |
+| 보안 | **평문 refresh token** 과 **로그아웃 후 잔존** — 둘 다 코드로 막아야 한다 |

docs/experiment-b3-refresh-token-contention.md

@@ -0,0 +1,270 @@
+# B-3 — 같은 refresh token 으로 동시에 갱신하면 → Q2
+
+브랜치 `feature/keycloak-b3-refresh-token-contention` ·
+증거 [`docs/evidence/b3-refresh-contention/`](evidence/b3-refresh-contention/) ·
+2026-09-04 15:15–15:25 KST
+
+선행: [`B-2`](experiment-b2-multi-instance-session.md) — 토큰이 공유되어야 경쟁이 성립한다
+
+**대응 질문** — [Q2 · Refresh Token Rotation과 다중 Replica 경쟁을 어떻게 처리할 것인가](https://hyeonworks.com/questions/refresh-rotation-replica-contention)
+
+> Q2 가 남긴 것: *"실제 Keycloak 응답과 session 영향은 아직 재현해 보지 않았다."*
+
+---
+
+## 0. 결론부터
+
+**"하나는 성공하고 하나는 실패한다"가 아니다. 세션이 파괴된다.**
+
+```
+5개를 동시에 보냈을 때 (rotation ON, maxReuse=0)
+
+  요청 1: 400  "Maximum allowed refresh token reuse exceeded"
+  요청 2: 400  "Session doesn't have required client"
+  요청 3: 400  "Session doesn't have required client"
+  요청 4: 400  "Session doesn't have required client"
+  요청 5: 200  (토큰 발급됨)
+
+  ★ 그런데 5번이 받은 토큰으로 다시 갱신하면 → 400
+```
+
+**이긴 요청조차 쓸 수 없는 토큰을 받는다.**
+
+| 구성 | 성공 | 이긴 토큰 재사용 | client_session |
+|---|---|---|---|
+| **A** rotation ON · maxReuse=0 | **1 / 5** | **400** | **0 — 파괴** |
+| **B** rotation OFF | **5 / 5** | 200 | **1 — 생존** |
+| **C** rotation ON · maxReuse=1 | **2 / 5** | **400** | **0 — 파괴** |
+
+**Q2 의 판정 기준** — *"실패가 사용자에게 노출되면 lock, 노출되지 않으면 재시도."*
+**재시도로 회복되지 않는다.** 세션 자체가 없어지므로 답은 **lock** 이다.
+
+---
+
+## 1. 전제를 Q2 에 맞춘다
+
+```bash
+kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh get realms/keycloak-patterns \
+  --fields revokeRefreshToken,refreshTokenMaxReuse,accessTokenLifespan
+```
+
+```json
+{ "revokeRefreshToken" : false, "refreshTokenMaxReuse" : 0, "accessTokenLifespan" : 60 }
+```
+
+**기본값은 rotation 이 꺼져 있었다.** Q2 는 *"realm 이 refresh token rotation 과
+재사용 허용 0회를 쓰게 되어서"* 를 전제로 하므로 맞춰야 한다.
+
+```bash
+kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
+  update realms/keycloak-patterns -s revokeRefreshToken=true -s refreshTokenMaxReuse=0
+```
+
+> **`revokeRefreshToken` 이 rotation 스위치다.** 이름이 "회전"이 아니라
+> "취소"인 것이 헷갈리는데, **켜면 새 토큰을 줄 때 옛 토큰을 무효화**한다.
+> `refreshTokenMaxReuse` 는 그 위에서 **몇 번까지 봐줄 것인가**이다.
+
+---
+
+## 2. 재현 — 진짜 동시성을 만든다
+
+B-2 에서 토큰이 PostgreSQL 로 공유되므로 두 replica 가 같은 항목을 본다.
+다만 **Keycloak 쪽 동작을 분리해서 보려면** BFF 를 거치지 않는 편이 낫다.
+
+```bash
+# 파드 안에서 5개를 동시에 띄우고 wait
+i=1; while [ $i -le 5 ]; do
+  ( curl -s -o /tmp/b$i -w "%{http_code}" -X POST $KC \
+      -d grant_type=refresh_token -d client_id=bff-confidential \
+      -d client_secret=bff-lab-secret -d refresh_token=$RT > /tmp/c$i ) &
+  i=$((i+1)); done
+wait
+```
+
+**순차 실행이면 재현되지 않는다.** `&` 로 띄우고 `wait` 해야 진짜로 겹친다.
+
+---
+
+## 3. 무슨 일이 일어났는가 — 기제
+
+오류 메시지가 **두 종류**인 것이 단서였다.
+
+| 메시지 | 뜻 |
+|---|---|
+| `Maximum allowed refresh token reuse exceeded` | **재사용 탐지가 발동** |
+| `Session doesn't have required client` | **그 여파** — client session 이 이미 없다 |
+
+DB 로 확인했다.
+
+```sql
+select us.user_session_id,
+       (select count(*) from offline_client_session cs
+         where cs.user_session_id = us.user_session_id) as client_sessions
+  from offline_user_session us where us.user_session_id = '<sid>';
+```
+
+```
+경쟁을 겪은 세션:  BvFiB01Rntz1FcLdf7zG4BNt   client_sessions = 0   ← 제거됨
+정상 세션(대조군): JT-XuepgutWcE273QwAnIXta   client_sessions = 1
+```
+
+**user session 은 남고 client session 만 제거된다.**
+
+```
+   user session        "이 브라우저는 labuser 로 로그인함"     ← 남는다
+     └─ client session "그중 bff-confidential 에 대한 상태"   ← 지워진다
+```
+
+그래서 오류가 `"Session doesn't have required client"` 다 —
+**세션은 있는데 그 클라이언트 몫이 없다.**
+
+### 그래서 이긴 요청도 죽는다
+
+```
+   t0  5개가 동시에 도착
+   t1  하나가 처리를 시작 → 새 토큰 발급 준비
+   t2  다른 것들이 같은 옛 토큰으로 들어옴 → 재사용 탐지 발동
+   t3  ★ client session 제거
+   t4  t1 의 응답이 나간다 → HTTP 200, 새 토큰
+   t5  그 토큰을 쓰면 → client session 이 없다 → 400
+```
+
+**애플리케이션은 200 을 받았으므로 성공했다고 믿는다.**
+다음 요청에서야 끊긴 것을 안다. **오류가 지연되어 나타난다.**
+
+---
+
+## 4. 정책을 바꿔 비교했다
+
+### 구성 B — rotation OFF
+
+```
+  1: 200   2: 200   3: 200   4: 200   5: 200
+  성공 5 / 5
+  이긴 토큰 재사용: HTTP 200
+  남은 client_session: 1
+```
+
+**전부 성공하고 세션도 멀쩡하다.** 같은 refresh token 을 계속 쓸 수 있으므로
+경쟁 자체가 성립하지 않는다.
+
+**대신 잃는 것** — 토큰이 유출되면 **만료까지 계속 쓸 수 있다.**
+rotation 의 목적이 그 창을 좁히는 것이었다.
+
+### 구성 C — rotation ON · maxReuse=1
+
+```
+  1: 200
+  2: 400  "Session doesn't have required client"
+  3: 200
+  4: 400  "Maximum allowed refresh token reuse exceeded"
+  5: 400  "Session doesn't have required client"
+  성공 2 / 5
+  이긴 토큰 재사용: HTTP 400
+  남은 client_session: 0
+```
+
+**허용치를 1로 올려도 세션은 파괴됐다.**
+
+> **`refreshTokenMaxReuse` 를 올리는 것은 해법이 아니다.**
+> 동시 요청이 N 개면 `maxReuse ≥ N-1` 이어야 하는데, 그러면
+> **rotation 의 보안 목적이 사라진다.** 값을 올려 버티려는 시도는
+> "몇 개까지 동시에 올 것인가"를 맞춰야 하는 문제로 바뀔 뿐이다.
+
+---
+
+## 5. Q2 검증 항목 대조
+
+| # | Q2 의 검증 | 결과 |
+|---|---|---|
+| 1 | 동시 갱신 시 각 replica 동작 | **1개만 200, 나머지 400. 그런데 200 도 무효** |
+| 2 | 사용자 화면에 로그인 만료로 보이나 일시 오류로 보이나 | **로그인 만료로 보인다** — 세션이 실제로 없어졌으므로 |
+| 3 | 새 token 을 다시 읽어 **재시도하면 성공하는가** | **★ 실패한다.** client session 이 없어 어떤 토큰도 안 통한다 |
+| 4 | 한 곳에서만 갱신할지 / 각자 하고 재시도할지 | **재시도로는 회복 불가 → 한 곳에서만** |
+| 5 | lock 을 어디에 두고 얼마나 / 잡은 채 죽으면 | **아래 6절** |
+| 6 | 갱신 실패를 로그인 만료와 구분할 수 있는가 | **구분할 필요가 없다 — 실제로 로그인 만료다** |
+| 7 | rotation 전제를 바꿔서 비교 | **구성 B/C 로 측정 완료** |
+
+**3번이 이 실험의 핵심이다.** Q2 는 "재시도하면 성공하는가"를 열어뒀는데,
+**답은 아니오**이고 그래서 판정 기준이 자동으로 lock 쪽으로 결정된다.
+
+---
+
+## 6. 그래서 무엇을 해야 하는가
+
+### lock 이 필요하다 — 그런데 어디에
+
+```
+   BFF replica 1 ─┐
+                  ├─▶ 같은 (client, principal) 항목
+   BFF replica 2 ─┘
+```
+
+**lock 은 저장소 쪽에 있어야 한다.** 프로세스 안의 `synchronized` 는
+replica 를 넘지 못한다.
+
+| 후보 | |
+|---|---|
+| **PostgreSQL 행 잠금** | `SELECT ... FOR UPDATE` — **A-0 에서 Keycloak 자신이 쓰는 방식** |
+| Redis 분산 lock | `SET NX PX` — TTL 로 스스로 풀린다 |
+| 갱신 전용 인스턴스 | 단일 지점. 그 인스턴스가 죽으면? |
+
+**첫 번째가 자연스럽다** — 토큰이 이미 PostgreSQL 에 있고(B-2),
+Keycloak 도 세션 갱신에 같은 기법을 쓴다.
+
+```sql
+-- A-0 에서 Keycloak 이 실제로 쓰는 것
+select VERSION from OFFLINE_USER_SESSION ... for no key update skip locked
+```
+
+### lock 을 잡은 채 죽으면 (Q2 미지수 5번)
+
+| 방식 | 프로세스가 죽으면 |
+|---|---|
+| **DB 행 잠금** | **연결이 끊기면 자동 해제** — 가장 안전하다 |
+| Redis lock + TTL | TTL 만료까지 막힌다. TTL 이 짧으면 **중복 갱신**, 길면 **정지** |
+
+**DB 잠금이 이 문제에서 유리한 이유가 여기 있다** — 잠금의 수명이
+**연결의 수명**과 묶여 있어 따로 관리할 것이 없다.
+
+**B-5(Redis 상실)에서 Redis lock 의 이 약점을 재볼 수 있다.**
+
+---
+
+## 7. 재현 절차 (명령어)
+
+```bash
+# 1. 전제 맞추기
+kubectl -n keycloak-lab exec keycloak-0 -- /opt/keycloak/bin/kcadm.sh \
+  update realms/keycloak-patterns -s revokeRefreshToken=true -s refreshTokenMaxReuse=0
+
+# 2. refresh token 하나 확보 (direct grant)
+curl -s -X POST $KC -d grant_type=password -d client_id=bff-confidential \
+  -d client_secret=bff-lab-secret -d username=labuser -d password=labpass -d scope=openid
+
+# 3. 동시에 5개 — & 와 wait 이 없으면 재현되지 않는다
+i=1; while [ $i -le 5 ]; do ( curl ... -d refresh_token=$RT > /tmp/c$i ) & i=$((i+1)); done; wait
+
+# 4. ★ 이긴 요청의 토큰을 다시 써본다 — 여기서 진짜 답이 나온다
+curl -s -o /dev/null -w '%{http_code}' -X POST $KC -d grant_type=refresh_token -d refresh_token=$NEW
+
+# 5. 기제 확인 — client session 이 지워졌는지
+kubectl -n keycloak-lab exec deploy/postgres -- psql -U keycloak -d keycloak -c \
+  "select us.user_session_id,
+          (select count(*) from offline_client_session cs
+            where cs.user_session_id = us.user_session_id) as client_sessions
+     from offline_user_session us where us.user_session_id = '<sid>'"
+
+# 6. 정책 비교 — revokeRefreshToken 과 refreshTokenMaxReuse 를 바꿔가며 3~5 반복
+```
+
+---
+
+## 8. 다음 실험에 남기는 것
+
+| 실험 | 이 실험이 준 것 |
+|---|---|
+| **B-5** Redis 상실 | Redis lock 을 쓴다면 **Redis 가 죽었을 때 갱신이 멈춘다** |
+| **B-6** 암호화 key 교체 | 같은 "동시 접근" 문제의 다른 얼굴 |
+| **A-6** 지연 주입 (기록 정정) | A-6 에서 낙관적 락 충돌이 0 이었던 이유가 확인된다 — **로그인은 새 행을 만들 뿐**이고, 다투는 것은 **여기서처럼 같은 항목을 갱신할 때**다 |
+| 설계 | **재시도로 회복되지 않는다 → lock.** Q2 의 판정 기준이 결정됐다 |