DongHyeonkaandClaude Opus 5
2109f726fe
기록 84편을 계약 에이전트로 다시 썼다. 기존 71편(kss 25 · virt 46)과, 계약에만 있고 안 쓰여 있던 새 글감 13편이다. 원장 84개를 열어 단계마다 스킬 영수증과 관문 종료 코드를 적었고 verify-pipeline-run.py 가 error 0 으로 닫는다. SSOT 결함 둘을 고쳤다. - kss 의 `약 58일` 이 반입 중 `약 59일` 로 바뀌어 있었다. 원 증거 파일이 「남은 일수: 88일 … 실제 갱신까지 약 58일」로 산수를 직접 적는다. D-4a 쪽 `약 59일` 은 강제 갱신 뒤(`VALID: 89 days`)라 맞는 값이라 그대로 뒀다. - virt §198 의 `11.6GB` 는 §178 의 원 측정 `Mem: 11648`(MiB)과 어긋나는데 원 가이드의 표기 그대로라 고치지 않고 쓰이는 자리에 대조를 적었다. 기록의 수치 오류 셋을 고쳤다 — CASE 요약의 「게스트 셋에 8240MB」(5120+3120 은 둘이다), k3s 편이 같은 것을 여섯·일곱·여덟로 세던 것, no-docker 편의 「셋을 더 든다」(§281 의 표는 네 행이고 디스크 행이 빠져 있었다). 계약을 셋 고쳤다. - kss 의 sourceRepository 리비전이 cdac9b8 이었는데 그 커밋에는 docs/guides/** 28개가 아예 없다. 9465582b 로 바꾸고, 반입한 바이트가 어느 커밋과도 같지 않다는 것을 측정값과 함께 적었다 — 반입은 커밋이 아니라 그 시점의 작업 트리에서 떠 온 것이다(kss 297/306 · virt 12/14 가 작업 트리와 같고, 200 커밋을 거슬러 전수 대조했을 때 가장 가까운 커밋도 28개가 어긋났다). - virt 계약이 「2026-09-11 재배분」이라고 적는데 SSOT 는 재배분 날짜를 적지 않고 재배분 뒤 값은 이미 2026-09-10 측정에 찍혀 있다. - kss 후보 대장이 지나친 절 아홉에 처분을 적었다(warn 9 → 0). 새 글감은 0건이고 넷은 앵커가 h3 슬러그의 접두가 아니라 중간 토막이라 검사기가 못 본 것이었다. style_profile.mjs 의 결함 둘을 고쳤다 — frontmatter 가 문장으로 세어져 (실측 398자짜리 「문장」 하나) 평균 길이를 기준 안으로 밀어 올리고 있었고, engPerSent 의 분자는 목록을 포함한 글에서, 분모는 목록을 걷어낸 글에서 세고 있었다(Question 기록에서 11.94 → 3.86). verify-pipeline.py 전 항목 PASS · error 0 · unittest 334건 OK. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
156 lines
11 KiB
Markdown
156 lines
11 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: a-primary-key-without-the-session-id
|
|
title: 기본키에 세션 id 가 없어서 두 번째 로그인이 첫 토큰을 덮어썼다
|
|
topic: where-application-state-lives
|
|
topicName: 세션과 토큰을 Redis 와 PostgreSQL 에 나눠 두기
|
|
project: keycloak-session-store
|
|
status: 게시 전
|
|
lastVerifiedOn:
|
|
sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
|
|
source:
|
|
- final/document.md#선택이-코드와-흐름에-반영되는-방식-b2
|
|
assets:
|
|
- key: b2-primary-key-overwrite
|
|
file: ../../../final/assets/b2-primary-key-overwrite/b2-primary-key-overwrite.svg
|
|
evidence:
|
|
- ../../../final/evidence/raw/b2-multi-instance-session__02-schema.txt
|
|
- ../../../final/evidence/raw/b2-multi-instance-session__04-overwrite-test.txt
|
|
---
|
|
|
|
# 기본키에 세션 id 가 없어서 두 번째 로그인이 첫 토큰을 덮어썼다
|
|
|
|
같은 사용자가 다시 로그인하자 앞의 토큰이 덮어써졌고, 로그아웃해도 토큰 행은 지워지지 않았다. 원인은 저장소 선택이 아니라 기본키였다. JdbcOAuth2AuthorizedClientService 의 기본 스키마는 client_registration_id 와 principal_name 둘로 기본키를 만들고 세션 id 를 넣지 않는다.
|
|
|
|
## 관계
|
|
|
|
- **세션과 인가된 클라이언트는 조회 키가 다르다**
|
|
두 저장소를 나눠 세운 이유를 그 기록이 설명한다.
|
|
- **세션만 Redis 로 옮기자 토큰이 따라오지 않았다**
|
|
그 실험이 세션 쪽만 옮겼고, 이 실험은 남은 토큰 쪽을 옮긴 다음을 쟀다.
|
|
- **저장소를 옮기기 전에 조회 키를 본다**
|
|
여기서 나온 관측을 반복 적용할 기준으로 편 것이다.
|
|
- **세션과 토큰의 저장소를 나눠 각각 설계한다**
|
|
「각각 설계한다」를 실제로 해 본 결과가 이 실험이다.
|
|
|
|
## 문제
|
|
|
|
세션과 토큰을 각각 다른 저장소로 옮기면 상태가 인스턴스 밖으로 나가므로, 다중 인스턴스 때문에 생기던 문제는 여기서 끝나야 한다. 정말 그런지를 네 가지로 나눠 순서대로 확인했다.
|
|
|
|
두 가지는 기대한 대로 됐는데 두 가지는 아니었다. 같은 사용자가 다른 브라우저로 다시 로그인하자 토큰 행이 늘지 않고 값만 바뀌었고, 로그아웃한 뒤 Redis 는 비었는데 PostgreSQL 에는 토큰 행이 하나 살아 있었다. 저장소를 옮겨서 풀릴 문제였다면 여기서 함께 풀렸어야 했다.
|
|
|
|
## 결론
|
|
|
|
네 가지 확인
|
|
다른 인스턴스로 요청해도 되는가 : o
|
|
재시작 후 로그인 유지 : o
|
|
같은 사용자의 다른 브라우저가 덮어쓰는가 : 덮어쓴다
|
|
로그아웃하면 두 저장소가 다 정리되는가 : 한쪽만
|
|
|
|
로그아웃 뒤 두 저장소
|
|
Redis 세션 : 0 키
|
|
PostgreSQL 토큰 : 1 행. 평문 refresh token 이 들어 있다
|
|
|
|
남은 두 문제의 원인은 기본키다. JdbcOAuth2AuthorizedClientService 가 쓰는 기본 스키마는 client_registration_id 와 principal_name 둘로만 기본키를 만들고 거기에 세션 id 가 없다. 같은 사용자가 두 번 로그인하면 principal 이름이 같으므로 두 세션이 한 행을 쓰게 되고, 나중 로그인이 앞의 토큰을 덮어쓴다.
|
|
|
|
저장소를 Redis 로 고르든 PostgreSQL 로 고르든 이 키가 같으면 결과도 같다.
|
|
|
|
## 검증 환경
|
|
|
|
실험대 : 베어메탈 한 대(test-server, Arch Linux, 12GB, WiFi only) 위의 VM 두 대
|
|
kc-lab-1 : k3s server (컨트롤 플레인) · keycloak-1
|
|
kc-lab-2 : k3s agent · keycloak-0 · PostgreSQL · Redis
|
|
애플리케이션 : BFF(Spring Boot) 두 인스턴스
|
|
세션 저장소 : Redis
|
|
토큰 저장소 : PostgreSQL. 구현은 JdbcOAuth2AuthorizedClientService
|
|
토큰 테이블 : oauth2_authorized_client
|
|
Keycloak 패치 버전 : 이 측정 기록에 적혀 있지 않다
|
|
Spring Boot 버전 : 이 측정 기록에 적혀 있지 않다
|
|
|
|
## 재현 조건
|
|
|
|
1. 세션 저장소를 Redis 로 두고 토큰 저장소를 JdbcOAuth2AuthorizedClientService 로 바꿔 배포한다.
|
|
|
|
2. 토큰 테이블의 기본키가 무엇인지 스키마에서 확인한다.
|
|
|
|
3. 로그인한 뒤 인스턴스 두 대에 번갈아 요청하고, 한 대를 재시작한 뒤 다시 요청한다.
|
|
|
|
4. 같은 사용자로 두 번째 로그인을 만든다.
|
|
브라우저를 바꾸거나 세션만 지우고 다시 로그인시키면 된다. principal 이름이 같으므로 조회 키가 같다.
|
|
|
|
5. 두 번째 로그인 뒤 토큰 테이블의 행 수와 access token 값을 앞의 것과 견준다.
|
|
|
|
6. 로그아웃한 뒤 Redis 의 키 수와 토큰 테이블의 행 수를 각각 센다.
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
## 저장소를 나눠 옮긴 다음
|
|
|
|
앞 실험에서 이 BFF(Backend For Frontend) 에는 저장소를 직접 만드는 빈이 없다는 것을 확인했다. 무엇이 쓰이는지는 자동구성 결과를 읽어야 알 수 있었는데, 읽어 보니 세션은 서블릿 컨테이너 메모리에 있었고 토큰은 인메모리 구현이 들고 있었다. 세션만 Redis 로 옮겼을 때 토큰이 따라오지 않은 이유도 거기 있었다.
|
|
|
|
그래서 이번에는 둘을 나눠서 옮겼다. 세션은 Redis 에 두고, 토큰은 `JdbcOAuth2AuthorizedClientService` 로 바꿔 PostgreSQL 에 넣었다. 이 구현은 인가된 클라이언트를 JVM 메모리에 두지 않고 관계형 데이터베이스의 테이블 하나를 읽고 쓴다. 둘 다 인스턴스 밖으로 나갔으니 확인할 것을 네 가지로 적고 하나씩 짚었다.
|
|
|
|
| 무엇을 확인했나 | 결과 |
|
|
|---|---|
|
|
| 다른 인스턴스로 요청해도 되는가 | 된다 |
|
|
| 재시작 후 로그인 유지 | 된다 |
|
|
| 같은 사용자의 다른 브라우저가 덮어쓰는가 | 덮어쓴다 |
|
|
| 로그아웃하면 두 저장소가 다 정리되는가 | 아니다. 한쪽만 |
|
|
|
|
앞의 두 가지는 상태가 인스턴스 밖으로 나갔으므로 풀렸다. 다만 이 둘은 판정만 남고 출력이 없다. 이 실험이 남긴 증거 원문 다섯 개는 배포·스키마·평문 토큰·덮어쓰기·로그아웃 정리인데, 다른 인스턴스로 요청한 화면도 재시작 뒤 로그인을 확인한 화면도 그중에 없다. 뒤의 두 가지와 같은 무게로 읽지 않는다.
|
|
|
|
뒤의 두 가지는 풀리지 않았다.
|
|
|
|
## 기본키를 만드는 두 칼럼
|
|
|
|
토큰 저장소를 바꿔 배포한 직후에는 테이블이 없었다. 파드는 떴고 커넥션 풀도 붙었는데 `oauth2_authorized_client` 를 조회하면 그런 이름의 테이블이 없다고 나왔고, 그것을 신고한 로그는 없었다. 스키마 초기화가 조용히 실패한 것이다.
|
|
|
|
`spring-security-oauth2-client` 는 DDL 을 두 벌 번들한다. 기본 판본인 `oauth2-client-schema.sql` 은 토큰 칼럼을 `blob` 으로 선언하고 `oauth2-client-schema-postgres.sql` 은 `bytea` 로 선언하는데, 기본 판본을 PostgreSQL 에 그대로 태우면 `blob` 에서 문법 오류가 난다. 그 오류를 삼킨 것은 `spring.sql.init.continue-on-error: true` 였다. 없어도 되는 초기화에만 켜는 설정인데 여기서는 없으면 안 되는 초기화였다.
|
|
|
|
원인을 처음에 Liquibase 의 방언 차이로 적었다가 정정했다. 스키마를 태우는 것은 Spring Boot 의 `spring.sql.init` 이고 DDL 은 `spring-security-oauth2-client` jar 가 번들한 파일이다. Liquibase 는 Keycloak 이 자기 스키마에 쓴다.
|
|
|
|
그래서 PostgreSQL 판 DDL 을 직접 태우고 만들어진 테이블 정의를 읽었다. 구현만 바꾸면 되겠다고 넘어가지 않고 그 줄을 먼저 본 것은, 조회 키가 코드가 아니라 스키마에 박혀 있기 때문이다. B-0 에서 자동구성이 고른 `AuthenticatedPrincipalOAuth2AuthorizedClientRepository` 라는 이름으로 짐작만 하던 것이 여기서 테이블 정의로 확정된다. 기본키를 만드는 칼럼은 둘이었다.
|
|
|
|
```sql label="인가 클라이언트 테이블의 기본키"
|
|
PRIMARY KEY (client_registration_id, principal_name)
|
|
```
|
|
|
|
클라이언트 등록 id 와 principal 이름 둘뿐이고 세션 id 가 없다. 같은 사용자가 브라우저를 바꿔 다시 로그인하면 세션 id 는 새로 발급되지만 principal 이름은 그대로이므로, 두 세션이 같은 행을 쓰게 되고 나중 로그인이 앞의 토큰을 덮어쓴다.
|
|
|
|
|
|
|
|
그림에서 세션 쪽은 브라우저마다 따로 있는데 토큰 행으로 들어가는 화살표는 둘 다 principal 이름을 타고 같은 행으로 모인다. 덮어쓰기가 일어났는지는 행 수로 알 수 없다. 행은 늘 1 이라 아무 일도 없는 것처럼 보이므로, access token 값이 바뀌었는지를 함께 본다.
|
|
|
|
두 번째 로그인은 브라우저를 두 개 띄워 만들지 않았다. Redis 에서 세션만 지워 다음 요청이 새 로그인을 만들게 했고, 브라우저가 달라도 principal 이름은 같으므로 조회 키는 그대로다. 그렇게 만든 재로그인 뒤 행 수는 1 이었고 access token 의 md5 가 바뀌었다.
|
|
|
|
```sql label="한 사용자에게 행이 몇 개 있는지"
|
|
select principal_name, count(*) from oauth2_authorized_client group by 1;
|
|
```
|
|
|
|
## 로그아웃이 지우는 쪽과 지우지 않는 쪽
|
|
|
|
네 번째 확인은 로그아웃이었다. 로그아웃하면 Redis 의 세션 키는 없어지는데, 토큰 테이블에서는 행이 하나도 지워지지 않는다.
|
|
|
|
```text label="로그아웃한 뒤 두 저장소"
|
|
Redis 세션 : 0 키 ← 정리됨
|
|
PostgreSQL 토큰 : 1 행 ← 평문 refresh token 이 그대로 남는다
|
|
```
|
|
|
|
로그아웃이 끝내는 것은 애플리케이션 세션이고, 인가된 클라이언트는 principal 이름으로 찾는 별개 저장소에 있어서 세션이 사라지는 것과 무관하게 유지된다. 그래서 로그아웃한 사용자의 refresh token 이 평문으로 데이터베이스에 앉아 있게 된다.
|
|
|
|
평문이라는 것은 칼럼 타입을 보고 짐작한 것이 아니라 저장된 바이트를 꺼내 디코드해서 확인했다. `bytea` 에 들어 있는 것은 암호화된 덩어리가 아니라 JWT 문자열 그대로였고, refresh token 쪽 헤더의 `alg` 는 `HS512`, access token 쪽은 `RS256` 으로 읽혔다. 데이터베이스 읽기 권한만 있으면 바로 쓸 수 있는 토큰을 얻는다.
|
|
|
|
## 저장소를 바꿔도 같은 일이 일어난다
|
|
|
|
덮어쓰기는 어느 저장소에 넣느냐가 아니라 어느 키로 행을 식별하느냐에서 나온다. 같은 스키마를 Redis 에 얹어도 키가 `client_registration_id` 와 `principal_name` 둘이면 같은 사용자의 두 세션이 같은 항목을 가리킨다.
|
|
|
|
같은 사용자가 두 브라우저를 쓸 때 한쪽의 로그인이 풀리는 것을 세션 만료나 캐시 문제로 보면 저장소만 계속 바꾸게 된다. 고쳐야 하는 것은 테이블을 만드는 DDL(Data Definition Language, 스키마 정의문) 쪽이다.
|
|
|
|
## 확인하지 않은 것
|
|
|
|
세션 id 를 키에 넣은 스키마로 고쳐서 다시 재지 않았다. 덮어쓰기가 사라지는지는 확인하지 않았다.
|
|
|
|
로그아웃할 때 토큰 행까지 지우는 처리를 붙였을 때 무엇이 달라지는지도 이 실험에서는 재지 않았다.
|
|
<!-- body:end -->
|