feat(pipeline): keycloak-session-store 25편·virtualization 59편을 S3→S5→S6 으로 돌린다
기록 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>
This commit is contained in:
DongHyeonka
co-authored by
Claude Opus 5
Claude Opus 5
parent
d473609e0a
commit
2109f726fe
+155
@@ -0,0 +1,155 @@
|
||||
---
|
||||
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 -->
|
||||
+150
@@ -0,0 +1,150 @@
|
||||
---
|
||||
kind: CASE
|
||||
slug: moving-the-session-left-the-tokens-behind
|
||||
title: 세션만 Redis 로 옮기자 토큰이 따라오지 않았다
|
||||
topic: where-application-state-lives
|
||||
topicName: 세션과 토큰을 Redis 와 PostgreSQL 에 나눠 두기
|
||||
project: keycloak-session-store
|
||||
status: 게시 전
|
||||
lastVerifiedOn: 2026-09-04
|
||||
sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
|
||||
source:
|
||||
- final/document.md#선택이-코드와-흐름에-반영되는-방식-b0
|
||||
- final/document.md#선택이-코드와-흐름에-반영되는-방식-b1
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/b0-bff-redis-deploy__03-beans-analysis.txt
|
||||
- ../../../final/evidence/raw/b1-redis-session-store__03-redis-contents.txt
|
||||
---
|
||||
|
||||
# 세션만 Redis 로 옮기자 토큰이 따라오지 않았다
|
||||
|
||||
세션 저장소만 Redis 로 바꿨더니 파드를 재시작해도 로그인은 유지됐는데 토큰은 살아남지 못했다. 세션은 세션 id 로 찾고 토큰은 principal 이름으로 찾으므로, 세션 저장소를 바꾸는 설정은 토큰 쪽 경로를 건드리지 않는다.
|
||||
|
||||
## 관계
|
||||
|
||||
- **세션과 인가된 클라이언트는 조회 키가 다르다**
|
||||
이 실험이 관측한 결과를 만든 구조를 그 기록이 설명한다.
|
||||
- **기본키에 세션 id 가 없어서 두 번째 로그인이 첫 토큰을 덮어썼다**
|
||||
세션과 따로 옮긴 토큰 저장소에서 무엇이 남았는지를 그 실험이 이어서 쟀다.
|
||||
- **세션과 토큰의 저장소를 나눠 각각 설계한다**
|
||||
이 관측이 그 결정의 근거다.
|
||||
|
||||
## 문제
|
||||
|
||||
BFF 인스턴스가 둘이고 요청이 어느 쪽으로 갈지 모르면 로그인 상태가 인스턴스 안에 있어서는 안 된다. 그래서 세션 저장소를 Redis 로 옮기는 것이 첫 수였다.
|
||||
|
||||
문제는 무엇이 옮겨지는지가 코드에 안 적혀 있다는 것이었다. 이 BFF 에는 세션 저장소나 토큰 저장소를 직접 만드는 빈이 없고 전부 자동구성이 고른다. 무엇이 실제로 쓰이는지 모르는 채로 저장소를 붙이면 옮겨진 것과 안 옮겨진 것을 가를 수 없다.
|
||||
|
||||
## 결론
|
||||
|
||||
자동구성이 고른 것
|
||||
세션 저장소 : 없음. 서블릿 컨테이너 메모리
|
||||
토큰 저장소 : InMemoryOAuth2AuthorizedClientService
|
||||
토큰 조회를 맡는 것 : AuthenticatedPrincipalOAuth2AuthorizedClientRepository
|
||||
Redis 와 Spring Session : x
|
||||
|
||||
세션만 Redis 로 옮긴 뒤
|
||||
파드 재시작 후 로그인 유지 : o
|
||||
파드 재시작 후 토큰 생존 : x
|
||||
Redis 에 들어간 키 : 1개. 타입은 hash
|
||||
그 해시에 인가된 클라이언트 필드 : x
|
||||
|
||||
세션은 세션 id 로 찾고 토큰은 principal 이름으로 찾는다. 조회 경로가 갈라져 있어서 세션 저장소를 무엇으로 바꾸든 토큰은 따라오지 않는다.
|
||||
|
||||
## 검증 환경
|
||||
|
||||
실험대 : 베어메탈 한 대(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) 두 인스턴스
|
||||
세션 저장소 전환 : 환경변수 SPRING_SESSION_STORE_TYPE 을 redis 로
|
||||
빈 목록 조회 : BFF 의 actuator beans 엔드포인트
|
||||
Keycloak 패치 버전 : 이 측정 기록에 적혀 있지 않다
|
||||
Spring Boot 버전 : 이 측정 기록에 적혀 있지 않다
|
||||
|
||||
## 재현 조건
|
||||
|
||||
1. 저장소를 아무것도 붙이지 않은 상태로 BFF 를 띄우고 로그인을 한 번 한다.
|
||||
|
||||
2. 빈 목록을 조회해 세션과 토큰에 관계된 구현이 무엇인지 확인한다.
|
||||
authorizedClientService · authorizedClientRepository · SessionRepository 세 이름을 본다.
|
||||
|
||||
3. 환경변수 SPRING_SESSION_STORE_TYPE 을 redis 로 두고 다시 배포한 뒤 로그인한다.
|
||||
|
||||
4. Redis 의 키를 세고 그 키의 타입과 필드 이름을 확인한다.
|
||||
|
||||
5. BFF 파드를 재시작하고 같은 브라우저로 요청한다.
|
||||
로그인이 유지되는지와 토큰이 필요한 요청이 되는지를 따로 본다.
|
||||
|
||||
## 본문
|
||||
|
||||
<!-- body:start -->
|
||||
## 저장소를 붙이기 전에 무엇이 골라져 있었나
|
||||
|
||||
이 BFF 의 코드에는 세션 저장소도 토큰 저장소도 직접 만드는 빈이 없다. 전부 자동구성이 고르므로 Redis 를 붙이기 전에 실행 중인 애플리케이션의 빈 목록을 먼저 읽었다. 전체 빈은 321개였고 그중 세션·토큰 저장소에 관계된 빈은 다섯 줄이었다. 그 다섯 줄에서 토큰을 담는 구현과 토큰을 조회하는 구현을 찾았고, 세션 쪽과 Redis 쪽에는 해당하는 빈이 없었다.
|
||||
|
||||
```text label="B-0 · 자동구성이 실제로 고른 구현체"
|
||||
authorizedClientService → InMemoryOAuth2AuthorizedClientService
|
||||
authorizedClientRepository → AuthenticatedPrincipalOAuth2AuthorizedClientRepository
|
||||
SessionRepository → 없음 (서블릿 컨테이너 in-memory)
|
||||
Redis / Spring Session → 없음
|
||||
```
|
||||
|
||||
`InMemoryOAuth2AuthorizedClientService` 는 발급받은 access token 과 refresh token 을 JVM 메모리에 담아 두는 기본 구현이다. `SessionRepository` 가 하나도 없다는 것은 Spring Session 이 구성되지 않았다는 뜻이므로, 로그인 상태는 서블릿 컨테이너가 자기 메모리에 들고 있었다. 두 가지 모두 인스턴스 안에 있었다.
|
||||
|
||||
빈 목록은 이렇게 뽑는다.
|
||||
|
||||
```bash label="무엇이 토큰을 맡고 있는지 확인"
|
||||
kubectl exec <bff-pod> -- wget -qO- localhost:8083/actuator/beans \
|
||||
| grep -o '"[a-zA-Z]*OAuth2AuthorizedClient[a-zA-Z]*"' | sort -u
|
||||
```
|
||||
|
||||
## 이름 하나가 조회 키를 말해 준다
|
||||
|
||||
`AuthenticatedPrincipalOAuth2AuthorizedClientRepository` 는 요청에 딸린 인증 주체(principal)의 이름으로 인가된 클라이언트를 찾아 주는 구현이다. 이름에 적힌 그대로 principal 을 기준으로 찾으므로 조회 키에 세션 id 가 들어가지 않는다.
|
||||
|
||||
| | 무엇을 담나 | 무엇으로 찾나 |
|
||||
|---|---|---|
|
||||
| Application Session | 누가 로그인했는지 | 세션 id |
|
||||
| OAuth2AuthorizedClient | access · refresh token | principal 이름 |
|
||||
|
||||
같은 요청 하나가 세션은 세션 id 로, 토큰은 principal 이름으로 두 갈래로 조회된다. 이름이 비슷해서 하나로 읽히지만 저장되는 것도 다르고 찾아오는 경로도 다르다.
|
||||
|
||||
## 세션만 옮기고 재시작했을 때
|
||||
|
||||
배포하자마자 파드가 안 떴다. 쿠버네티스는 같은 네임스페이스의 Service 마다 환경변수를 자동으로 넣는데, 그중 `REDIS_PORT=tcp://10.43.57.116:6379` 가 `application.yml` 의 `${REDIS_PORT:6379}` 를 덮어써 `spring.data.redis.port` 를 int 로 바꾸지 못했다. 환경변수 이름을 바꿔 피할 수도 있었지만 그러면 다음 사람이 같은 함정에 다시 빠지므로, 주입 자체를 끄는 `enableServiceLinks: false` 를 골랐다.
|
||||
|
||||
환경변수 `SPRING_SESSION_STORE_TYPE` 을 `redis` 로 두어 Application Session 을 Redis 로 옮겼다. 파드를 재시작해도 로그인은 유지됐다. 브라우저는 다시 로그인 화면을 보지 않았고 같은 세션으로 요청이 이어졌다.
|
||||
|
||||
그런데 같은 재시작에서 토큰은 살아남지 못했다. `OAuth2AuthorizedClient` 를 찾는 경로가 principal 이름을 쓰는 인메모리 구현 그대로였기 때문이다. 세션 저장소를 Redis 로 바꾸는 설정은 세션 쪽 경로만 갈아 끼우므로 토큰 쪽은 건드리지 않는다.
|
||||
|
||||
## Redis 안에 들어간 것
|
||||
|
||||
옮긴 뒤 Redis 를 열어 보니 키가 하나였고 타입은 hash 였다.
|
||||
|
||||
```text label="B-1 · Redis 에 들어 있던 세션 키"
|
||||
bff:session:sessions:8963b6de-3564-4775-9ccd-1ee9616b83ae
|
||||
총 키 수: 1
|
||||
타입: 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
|
||||
TTL: 1772 초
|
||||
```
|
||||
|
||||
필드 이름에 토큰이 안 보이는 것과 값 안에 토큰이 없는 것은 다른 말이라, 필드 값도 직접 꺼내 토큰 문자열이 섞여 있는지 봤다. `sessionAttr:SPRING_SECURITY_CONTEXT` 의 값은 `\xac\xed` 두 바이트로 시작한다. Java 기본 직렬화의 매직 넘버라, Redis 에 들어간 값은 같은 클래스패스의 JVM 이 있어야 읽힌다. 그 안에 든 것은 누가 로그인했는지를 말하는 인증 객체다. 일곱 필드 어느 이름도 access token 이나 refresh token 을 가리키지 않는다.
|
||||
|
||||
값을 꺼내 본 것은 `sessionAttr:SPRING_SECURITY_CONTEXT` 하나뿐이다. 이름에 OAuth2 가 들어간 `…HttpSessionOAuth2AuthorizationRequestRepository.AUTHORIZATION_REQUEST` 는 이름만 보고 넘어갔고 값 안을 열어 보지 않았다.
|
||||
|
||||
로그인 상태가 Redis 로 나간 것은 맞지만 토큰은 아직 인스턴스 메모리에 있었다. 여기서 「무상태가 됐다」고 판단하면 다른 인스턴스로 간 요청이 토큰을 못 찾는 이유를 설명할 수 없게 된다.
|
||||
|
||||
## 확인하지 않은 것
|
||||
|
||||
Redis 를 붙인 상태에서 토큰 저장소만 따로 두는 조합은 B-2 에서 다시 쟀다. 여기서는 세션 쪽만 확인했다. 그 실험이 확인한 네 가지 가운데 둘은 저장소를 밖으로 빼는 것으로 풀렸고 둘은 풀리지 않았는데, 남은 둘의 원인은 저장소가 아니라 토큰 테이블의 기본키였다.
|
||||
|
||||
파드 재시작 한 번으로 본 결과이고, 두 인스턴스 사이로 요청을 번갈아 보내 토큰이 어느 쪽에서 사라지는지까지는 이 실험에서 재지 않았다.
|
||||
<!-- body:end -->
|
||||
+149
@@ -0,0 +1,149 @@
|
||||
---
|
||||
kind: CASE
|
||||
slug: persistence-without-a-volume-and-rotation-without-overlap
|
||||
title: 볼륨 없는 영속화와 유예 없는 키 회전
|
||||
topic: where-application-state-lives
|
||||
topicName: 세션과 토큰을 Redis 와 PostgreSQL 에 나눠 두기
|
||||
project: keycloak-session-store
|
||||
status: 게시 전
|
||||
lastVerifiedOn:
|
||||
sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
|
||||
source:
|
||||
- final/document.md#선택이-코드와-흐름에-반영되는-방식-b5-b6
|
||||
assets:
|
||||
- key: b5-b6-storage-and-keys
|
||||
file: ../../../final/assets/b5-b6-storage-and-keys/b5-b6-storage-and-keys.svg
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/b5-redis-loss__04-persistence.txt
|
||||
- ../../../final/evidence/raw/b6-key-rotation__03-old-key-removed.txt
|
||||
---
|
||||
|
||||
# 볼륨 없는 영속화와 유예 없는 키 회전
|
||||
|
||||
appendonly 를 켠 Redis 파드를 지웠더니 재기동 뒤 dbsize 가 0 이었고, realm 키 회전에서 기대한 JWKS 캐시 유예 구간은 없었다. 데이터 디렉터리가 컨테이너와 함께 사라졌고, NimbusJwtDecoder 는 모르는 kid 를 만나면 JWKS 를 다시 가져오므로 회전은 끊기지 않았다.
|
||||
|
||||
## 관계
|
||||
|
||||
- **세션만 Redis 로 옮기자 토큰이 따라오지 않았다**
|
||||
그 실험이 상태를 Redis 로 옮겼고, 이 실험은 그 Redis 가 죽었을 때 무엇이 남는지를 쟀다.
|
||||
- **저장소를 옮기기 전에 조회 키를 본다**
|
||||
저장소를 고를 때 설정과 매체를 나눠 보는 이 관측이 그 기준에 붙는다.
|
||||
|
||||
## 문제
|
||||
|
||||
세션을 Redis 로 옮기고 나면 Redis 가 내려갔을 때 무엇이 남는지가 다음 물음이 된다. 영속화 설정은 명령 한 줄로 켤 수 있고 켜고 나면 설정 조회에도 yes 로 나오므로, 설정만 보면 로그인 상태가 재기동 뒤에도 살아남는 구성으로 읽힌다.
|
||||
|
||||
키 쪽도 비슷하다. realm 의 서명 키를 바꾸면 그 전에 발급된 토큰이 한동안 남아 있는데, 검증하는 쪽이 옛 키를 언제까지 받아 주는지는 캐시 설정에 안 적혀 있다. 두 곳 모두 설정 값만으로는 답이 나오지 않아서 실제로 죽여 보고 회전시켜야 했다.
|
||||
|
||||
## 결론
|
||||
|
||||
Redis 영속화
|
||||
appendonly 설정 : yes 로 적용된다
|
||||
appendonlydir 생성 : o
|
||||
파드를 지운 뒤 재기동 : dbsize 0. 심어 둔 키 둘 다 없음
|
||||
재기동 후 appendonly : no
|
||||
원인 : 데이터 디렉터리가 컨테이너 파일시스템이라 컨테이너가 사라질 때 같이 사라진다
|
||||
|
||||
realm 키 회전
|
||||
기대한 JWKS 캐시 유예 구간 : x
|
||||
모르는 kid 를 만난 검증기의 동작 : 캐시 만료를 안 기다리고 JWKS 재조회
|
||||
옛 키를 남겨 둔 동안 옛 토큰 검증 : 이어진다
|
||||
옛 키 공급자를 제거한 뒤 옛 토큰 : 401
|
||||
같은 시점의 새 토큰 : 200
|
||||
|
||||
설정 값과 그 설정이 얹힌 매체는 따로 봐야 한다. 영속화는 설정이 맞아도 매체가 사라지면 뜻이 없고, 키 회전은 설정에 유예가 없어도 검증기가 다시 가져오므로 끊기지 않는다.
|
||||
|
||||
## 검증 환경
|
||||
|
||||
실험대 : 베어메탈 한 대(test-server, Arch Linux, 12GB, WiFi only) 위의 VM 두 대
|
||||
kc-lab-1 : k3s server (컨트롤 플레인) · keycloak-1
|
||||
kc-lab-2 : k3s agent · keycloak-0 · PostgreSQL · Redis
|
||||
세션 저장소 : Redis. 볼륨을 붙이지 않은 상태
|
||||
영속화 설정 : redis-cli 로 appendonly 를 yes 로
|
||||
리소스 서버 토큰 검증 : NimbusJwtDecoder
|
||||
키 회전 방식 : 새 RSA 공급자를 더 높은 priority 로 추가
|
||||
Keycloak 패치 버전 : 이 측정 기록에 적혀 있지 않다
|
||||
|
||||
## 재현 조건
|
||||
|
||||
1. 볼륨을 붙이지 않은 Redis 에 키를 두어 개 심고 dbsize 를 센다.
|
||||
|
||||
2. appendonly 를 yes 로 바꾸고 설정 조회로 적용됐는지 확인한다.
|
||||
데이터 디렉터리에 appendonlydir 이 생겼는지도 본다.
|
||||
|
||||
3. Redis 파드를 지우고 다시 뜨기를 기다린 뒤 dbsize 와 심어 둔 키를 다시 조회한다.
|
||||
appendonly 값도 같이 본다.
|
||||
|
||||
4. realm 에 새 RSA 키 공급자를 더 높은 priority 로 추가한다.
|
||||
|
||||
5. 회전 전에 받아 둔 옛 토큰과 회전 뒤에 받은 새 토큰으로 보호된 요청을 각각 보낸다.
|
||||
|
||||
6. 옛 RSA 공급자를 제거하고 5 번을 다시 보낸다.
|
||||
리소스 서버를 재시작해 JWKS 캐시를 비운 뒤에도 한 번 더 보낸다.
|
||||
|
||||
## 본문
|
||||
|
||||
<!-- body:start -->
|
||||
## 영속화를 켜도 재기동 뒤에 아무것도 없었다
|
||||
|
||||
Redis 에 세션을 두었으니 Redis 가 내려갔다 올라올 때 세션이 남는지를 봐야 했다. 손대기 전 Redis 는 영속화가 아예 꺼져 있었다. `config get save` 의 값 줄이 비어 있어 스냅샷 조건이 없었고 `appendonly` 도 `no` 였다.
|
||||
|
||||
`appendonly` 는 Redis 가 받은 쓰기 명령을 파일에 덧붙여 적어 두고 재기동할 때 그 파일을 다시 재생하는 설정이다. 실행 중에 `redis-cli config set` 으로 켤 수 있고, 켜고 나면 설정 조회에 `yes` 로 나오고 데이터 디렉터리에 `appendonlydir` 도 생긴다. 여기까지가 설정 조회로 볼 수 있는 전부이고, 이 둘만 보면 켜진 것과 남는 것이 같은 말로 보인다.
|
||||
|
||||
그래서 읽는 대신 지웠다. 키를 심고 그 상태에서 파드를 지웠다.
|
||||
|
||||
```text label="B-5 · 파드를 지우고 재기동한 뒤"
|
||||
재기동 후:
|
||||
dbsize: 0
|
||||
b5:probe
|
||||
b5:aof
|
||||
appendonly no
|
||||
```
|
||||
|
||||
심어 둔 키 둘은 값이 비어 있었고 데이터베이스 크기는 0 이었다. `appendonly` 도 `no` 로 돌아와 있었는데, 실행 중에 바꾼 설정이라 새로 뜬 컨테이너는 이미지의 기본 설정으로 시작하기 때문이다.
|
||||
|
||||
## 파일을 어디에 적었는지가 남는 것을 정한다
|
||||
|
||||
덧붙여 적는 파일이 컨테이너 안의 `/data` 에 있었다. 컨테이너 파일시스템은 컨테이너가 사라질 때 같이 사라지므로, 파드를 지우는 순간 `appendonlydir` 도 없어졌다. 설정은 제대로 적용됐고 파일도 만들어졌는데 그 파일을 둔 곳이 컨테이너와 수명을 같이했다.
|
||||
|
||||
Redis 는 이것을 모른다. `appendonly yes` 를 켜면 `/data` 에 `appendonlydir` 을 만들고 매 쓰기를 기록한다. 거짓말을 하는 것이 아니라 정말로 기록하고, 다만 그 디렉터리가 어디에 얹혀 있는지를 모를 뿐이다. 그래서 설정 조회로는 이 실패가 보이지 않고, 대신 파드 명세에서 세 가지가 전부 성립하는지를 본다. `volumes` 에 항목이 있는지, 그 `volumeMounts` 의 `mountPath` 가 `/data` 인지, `PersistentVolumeClaim` 이 `Bound` 인지. 하나라도 빠지면 `appendonly yes` 는 아무것도 지키지 못하고, 파일은 만들어지고 로그도 정상인데 재시작하면 사라진다.
|
||||
|
||||
`emptyDir` 로 붙여도 마찬가지다. 컨테이너 재시작은 견디지만 파드가 없어지면 같이 없어지므로, 볼륨을 붙였다는 것과 영속 볼륨을 붙였다는 것은 다른 말이다.
|
||||
|
||||
|
||||
|
||||
그림에서 `appendonly yes` 는 `/data` 로 이어지고, `/data` 에서 나가는 화살표는 둘이다. 하나는 컨테이너와 함께 사라지는 쪽이고 하나는 `PersistentVolume` 으로 마운트되는 쪽이다. 위 측정은 마운트가 없는 상태였으므로 왼쪽 화살표만 실제로 일어났다.
|
||||
|
||||
지금 이 실험대의 매니페스트는 오른쪽이다. 측정한 결과가 그대로 반영되어 PersistentVolumeClaim 과 `--appendonly yes` 가 들어 있고, 그래서 같은 측정을 다시 하려면 볼륨 없는 상태를 먼저 되만드는 단계가 앞에 붙는다.
|
||||
|
||||
## realm 키를 회전했을 때 기대한 유예 구간
|
||||
|
||||
원래 물어야 했던 것은 토큰 저장소의 암호화 키를 어디에 두고 어떻게 교체하느냐였다. 그런데 앞 실험에서 `bytea` 안을 열어 보니 JWT 문자열이 그대로 들어 있었다. 저장소 쪽에는 교체할 키가 없으므로 남은 것은 서명 키 하나이고, 그래서 realm 의 RSA 공급자를 회전시켰다.
|
||||
|
||||
서명 키 쪽은 반대 방향으로 어긋났다. 토큰을 검증하는 쪽은 JWKS(JSON Web Key Set, 발급자가 서명에 쓴 공개키 목록)를 받아 캐시해 두고, 토큰 헤더의 `kid` 로 어느 키가 서명했는지 찾는다. 캐시가 있으니 회전 직후에는 옛 키 목록을 들고 있을 것이고, 캐시가 만료될 때까지 새 키로 서명된 토큰이 거부되는 구간이 있을 것으로 봤다.
|
||||
|
||||
그런 구간이 없었다. `NimbusJwtDecoder` 는 Spring Security 가 쓰는 JWT 검증기인데, 캐시에 없는 `kid` 를 만나면 만료를 기다리지 않고 JWKS 를 곧바로 다시 가져온다. 예측이 틀렸고, 회전은 그 구간 없이 그대로 이어졌다.
|
||||
|
||||
회전은 키 공급자의 우선순위로 한다. 새 키를 더 높은 priority 로 추가하면 그 뒤에 발급되는 토큰은 새 키로 서명되고, 옛 키는 목록에 있으므로 회전 전에 나간 토큰의 검증도 이어진다. JWKS 의 RS256 키는 회전 전 1개에서 회전 뒤 2개가 됐고, 회전 전에 받아 둔 토큰과 회전 뒤에 받은 토큰이 둘 다 200 이었다.
|
||||
|
||||
## 옛 키 공급자를 지우면 그때 끊긴다
|
||||
|
||||
옛 RSA 공급자를 realm 에서 제거하면 JWKS 에서 그 키가 빠진다. 그 시점부터 옛 키로 서명된 토큰은 검증할 공개키가 없다. 제거한 뒤 JWKS 를 다시 받아 RS256 키가 하나만 남은 것을 확인하고 나서 두 토큰을 보냈다.
|
||||
|
||||
```text label="B-6 · 옛 키 공급자를 제거한 뒤"
|
||||
옛 토큰 /api/me HTTP 401 (캐시가 살아 있으면 아직 통할 수 있다)
|
||||
새 토큰 /api/me HTTP 200
|
||||
```
|
||||
|
||||
리소스 서버를 재시작해 JWKS 캐시를 비운 뒤에도 같은 값이 나왔다. 옛 토큰은 401, 새 토큰은 200 이었다. 회전에서 옛 토큰을 살려 두는 것은 캐시가 아니라 realm 에 옛 키 공급자를 남겨 두는 쪽이다.
|
||||
|
||||
키 교체라는 한 낱말이 여기서는 성질이 반대인 두 조작이다. 키를 더하는 쪽은 아무것도 끊지 않고 JWKS 에 옛 키와 새 키가 함께 남는다. 옛 키를 버리는 쪽은 그 순간부터 끊는다. 위험한 것은 회전 자체가 아니라 옛 키를 언제 버리느냐다.
|
||||
|
||||
버린 키는 돌아오지도 않는다. 같은 이름으로 공급자를 다시 만들어도 새 키 쌍이 생겨 `kid` 가 달라지므로 옛 키로 서명된 토큰은 영구히 검증되지 않는다. 이 실험에서 되돌릴 수 있었던 것은 새로 만든 공급자를 지우는 쪽 하나뿐이었다.
|
||||
|
||||
## 확인하지 않은 것
|
||||
|
||||
볼륨을 붙인 Redis 로 B-5 전체를 다시 돌리지 않았다. 증거 원문에는 PersistentVolumeClaim 을 붙이고 키 하나를 심은 뒤 파드를 지웠더니 재기동 후에도 그 키가 남아 있었다는 기록이 한 번 있다. 다만 영속화가 어느 시점까지 복구하는지는 이 실험에서 재지 않았다.
|
||||
|
||||
키 회전 쪽은 옛 공급자를 남긴 경우와 제거한 경우 두 가지만 걸었다. 옛 키를 얼마나 오래 남겨 두어야 나간 토큰이 전부 만료되는지는 확인하지 않았다.
|
||||
<!-- body:end -->
|
||||
+159
@@ -0,0 +1,159 @@
|
||||
---
|
||||
kind: CASE
|
||||
slug: the-winner-of-the-rotation-race-also-loses
|
||||
title: 회전 경쟁에서 이긴 요청의 토큰도 쓸 수 없었다
|
||||
topic: where-application-state-lives
|
||||
topicName: 세션과 토큰을 Redis 와 PostgreSQL 에 나눠 두기
|
||||
project: keycloak-session-store
|
||||
status: 게시 전
|
||||
lastVerifiedOn:
|
||||
sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
|
||||
source:
|
||||
- final/document.md#선택이-코드와-흐름에-반영되는-방식-b3
|
||||
assets:
|
||||
- key: b3-rotation-contention
|
||||
file: ../../../final/assets/b3-rotation-contention/b3-rotation-contention.svg
|
||||
evidence:
|
||||
- ../../../final/evidence/raw/b3-refresh-contention__01-concurrent-refresh.txt
|
||||
- ../../../final/evidence/raw/b3-refresh-contention__02-session-impact.txt
|
||||
- ../../../final/evidence/raw/b3-refresh-contention__03-client-session-removed.txt
|
||||
- ../../../final/evidence/raw/b3-refresh-contention__04-policy-comparison.txt
|
||||
---
|
||||
|
||||
# 회전 경쟁에서 이긴 요청의 토큰도 쓸 수 없었다
|
||||
|
||||
같은 refresh token 으로 동시에 5건을 보내자 이긴 요청의 새 토큰도 쓸 수 없었다. 경쟁이 감지되자 Keycloak 이 client session 을 지웠기 때문이다. 다섯 전부 못 쓰게 되므로 재시도를 「실패한 것만 다시 보낸다」로 설계할 수 없고, 복구하려면 다시 로그인해야 한다.
|
||||
|
||||
## 관계
|
||||
|
||||
- **기본키에 세션 id 가 없어서 두 번째 로그인이 첫 토큰을 덮어썼다**
|
||||
그 실험은 저장된 토큰이 서로를 덮어쓰는 것을 쟀고, 이 실험은 같은 토큰을 동시에 쓸 때를 쟀다.
|
||||
- **세션과 토큰의 저장소를 나눠 각각 설계한다**
|
||||
토큰 쪽 설계에 재시도가 왜 따라붙는지를 이 관측이 댄다.
|
||||
|
||||
## 문제
|
||||
|
||||
토큰 갱신에 성공하면 Keycloak 은 새 refresh token 을 발급하면서 옛것을 소비된 것으로 표시하므로, 그 토큰이 다시 오면 재사용으로 본다. 이 realm 은 회전을 켜고 재사용 허용을 0 으로 두어 한 번만 쓸 수 있게 해 두었다.
|
||||
|
||||
인스턴스가 둘이고 요청이 어느 쪽으로 갈지 모르는 구성에서는 두 replica 가 같은 refresh token 을 거의 같은 시각에 쓸 수 있다. 이때 하나가 이기고 나머지가 400 을 받는다면 진 요청만 다시 보내는 재시도로 복구된다. 실제로 그렇게 갈리는지를 재야 했다.
|
||||
|
||||
## 결론
|
||||
|
||||
realm 설정
|
||||
revokeRefreshToken : true
|
||||
refreshTokenMaxReuse : 0
|
||||
|
||||
같은 refresh token 으로 동시에 5건을 보낸 결과
|
||||
순차 실행으로 재현 : x
|
||||
이긴 요청이 새 토큰을 받았는가 : o
|
||||
이긴 요청의 새 토큰을 쓸 수 있었는가 : x
|
||||
원인 : 경쟁이 감지되자 Keycloak 이 client session 을 지웠다
|
||||
|
||||
회전을 느슨하게 둔 두 구성을 같은 절차로 더 걸었을 때
|
||||
revokeRefreshToken false : 5건 다 200. client session 1 남음
|
||||
refreshTokenMaxReuse 1 : 성공 2 / 5. 이긴 토큰 재사용 400. client session 0
|
||||
|
||||
「하나는 성공하고 나머지가 실패한다」가 아니라 전부 못 쓰게 되는 쪽이었다. 새 토큰 자체가 잘못 발급된 것이 아니라 그 토큰이 매달린 세션이 방금 사라졌기 때문이다.
|
||||
|
||||
그래서 이 상황의 복구는 실패한 요청을 다시 보내는 것으로 끝나지 않고 재인증까지 가야 한다.
|
||||
|
||||
## 검증 환경
|
||||
|
||||
실험대 : 베어메탈 한 대(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) 두 인스턴스. 노드마다 하나씩 떴다
|
||||
회전 설정 : revokeRefreshToken true · refreshTokenMaxReuse 0
|
||||
정책 비교로 더 건 두 구성 : revokeRefreshToken false · refreshTokenMaxReuse 1
|
||||
동시 요청 수 : 5. 세 구성 모두 같은 수로 걸었다
|
||||
Keycloak 패치 버전 : 이 측정 기록에 적혀 있지 않다
|
||||
|
||||
## 재현 조건
|
||||
|
||||
1. realm 의 회전 설정을 확인한다.
|
||||
revokeRefreshToken 이 true 이고 refreshTokenMaxReuse 가 0 이어야 한다.
|
||||
|
||||
2. 로그인해서 refresh token 을 하나 확보한다.
|
||||
|
||||
3. 그 토큰 하나로 토큰 갱신 요청 5건을 동시에 보낸다.
|
||||
셸에서 각 요청을 백그라운드로 띄우고 wait 으로 모은다. 순차로 돌리면 경합이 생기지 않아 재현되지 않는다.
|
||||
|
||||
4. 5건의 응답 코드를 각각 기록한다.
|
||||
|
||||
5. 200 을 받은 요청이 가져온 새 access token 으로 보호된 요청을 한 번 보낸다.
|
||||
|
||||
6. 그 사용자의 세션에 client session 이 몇 개 남았는지 확인하고, 새로 만든 정상 세션과 견준다.
|
||||
같은 시점에 revoked_token 행 수도 센다.
|
||||
|
||||
7. 회전 설정을 바꾸기 전에 세션을 새로 만든다.
|
||||
앞 구성에서 파괴된 세션으로 재면 무엇을 바꾸든 다섯 다 400 이라 비교가 성립하지 않는다.
|
||||
|
||||
8. 회전을 끈 구성과 refreshTokenMaxReuse 를 1 로 둔 구성에서 3 번부터 6 번까지를 각각 다시 돌린다.
|
||||
|
||||
## 본문
|
||||
|
||||
<!-- body:start -->
|
||||
## 회전을 켜면 옛 토큰이 소비된 것으로 표시된다
|
||||
|
||||
토큰 갱신에 성공하면 Keycloak 은 새 refresh token 을 발급하면서 방금 쓴 토큰을 소비된 것으로 표시한다. 소비된 토큰이 다시 오면 재사용으로 보고 거절하는데, 얼마나 엄격하게 볼지는 realm 설정 두 개가 정한다.
|
||||
|
||||
| 설정 | 무엇을 바꾸나 |
|
||||
|---|---|
|
||||
| revokeRefreshToken | 회전을 켠다. 옛 토큰을 소비 처리 |
|
||||
| refreshTokenMaxReuse=0 | 한 번만 쓸 수 있다 (가장 엄격) |
|
||||
| refreshTokenMaxReuse=1 | 같은 토큰을 두 번까지 허용 — 네트워크 재시도를 견디려는 값 |
|
||||
|
||||
동시 5건을 처음 던진 것은 가장 엄격한 쪽인 `refreshTokenMaxReuse=0` 에서였다. 지금 realm 이 어느 쪽인지는 관리 명령으로 확인한다.
|
||||
|
||||
```bash label="realm 의 회전 설정"
|
||||
kcadm get realms/<realm> --fields revokeRefreshToken,refreshTokenMaxReuse
|
||||
```
|
||||
|
||||
## 순차로 보내면 아무 일도 일어나지 않는다
|
||||
|
||||
replica 둘이 같은 refresh token 을 쓰는 상황을 만들려면 요청이 실제로 겹쳐야 한다. 같은 토큰으로 5건을 차례로 보내면 첫 건이 갱신하고 나머지가 소비된 토큰을 들고 오므로 재사용 판정이 순서대로 나올 뿐이다. 그래서 셸에서 요청 5건을 `&` 로 띄우고 `wait` 으로 한꺼번에 모아 같은 시각에 도착하게 만들었다.
|
||||
|
||||
부하 도구는 쓰지 않았다. 묻는 것이 초당 몇 건까지 견디는가가 아니라 겹치면 무엇이 부서지는가라서, 둘만 겹쳐도 답은 나온다. 5건으로 잡은 것은 뒤에 나오는 오류 문구 두 종류가 한 화면에 같이 보이기 때문이지 다섯이 필요해서가 아니다.
|
||||
|
||||
## 이긴 요청의 토큰도 쓸 수 없었다
|
||||
|
||||
동시에 보낸 5건 가운데 하나는 새 토큰을 받았다. 나머지 넷이 받은 400 은 한 가지가 아니었다. 한 건만 `Maximum allowed refresh token reuse exceeded` 였고 나머지 셋은 `Session doesn't have required client` 였다 — 뒤의 셋은 회전 판정이 아니라 세션 쪽에서 거절됐다.
|
||||
|
||||
이긴 요청의 새 토큰으로 보호된 요청을 보내자 그것도 통하지 않았다. 재사용이 감지된 순간 Keycloak 이 그 토큰만 막은 것이 아니라 세션 쪽을 지웠기 때문이다. 이긴 요청이 받은 토큰은 방금 사라진 client session 에 매달려 있어서 검증을 통과하지 못한다.
|
||||
|
||||
이긴 요청이 200 을 받은 것 자체는 어긋난 값이 아니다. 그 요청은 먼저 처리를 시작해 새 토큰 발급까지 갔고, 그 사이에 뒤늦게 도착한 것들이 같은 옛 토큰을 들고 오면서 재사용 탐지를 깨웠다. client session 이 지워진 것은 그 다음이고, 200 응답은 이미 성공이 확정된 상태로 나간다. 두 일의 순서가 전부라서, 응답 코드를 아무리 봐도 그 토큰이 죽었다는 것은 안 보인다.
|
||||
|
||||
이 판정은 값 하나만 보고 내리지 않았다. 경합을 겪은 sid 는 user session 행이 남아 있고 client session 만 0 이었는데, 그 0 이 원래 그런 값인지 지워진 결과인지는 값 하나로 구분되지 않는다. 그래서 정상 세션을 하나 새로 만들어 같은 질의를 걸었고, 그쪽은 1 이었다.
|
||||
|
||||
토큰을 폐기 목록에 올려 막은 것일 가능성도 함께 지웠다. 같은 시점에 `revoked_token` 을 세었더니 0 행이었다. 토큰을 지우는 방식이었다면 그 client 의 다른 토큰은 살아 있어야 하는데, 여기서는 그 client 몫이 한꺼번에 죽는다.
|
||||
|
||||
|
||||
|
||||
그림에서 동시 요청 다섯이 회전 검사로 모이고, 거기서 나가는 화살표는 client session 을 지우는 쪽으로 간다. 이긴 요청의 새 토큰으로 향하는 선은 그 삭제 뒤에 놓인다. 「하나는 성공하고 나머지가 실패한다」가 아니라 다섯 전부 못 쓰게 되는 쪽이었다.
|
||||
|
||||
## 재시도 설계가 여기서 갈린다
|
||||
|
||||
실패가 진 요청에만 온다면 재시도는 400 을 받은 쪽만 다시 보내면 끝난다. 200 을 받은 요청까지 쓸 수 없으므로 그 설계로는 복구되지 않고, 이 사용자는 다시 로그인해야 한다.
|
||||
|
||||
그러면 회전 설정을 느슨하게 두는 쪽은 어떤지를 같은 절차로 두 번 더 걸었다. 걸기 전에 세션을 새로 만드는 것이 전제인데, 방금 파괴된 세션으로 재면 설정을 무엇으로 두든 다섯 다 400 이라 비교가 성립하지 않는다.
|
||||
|
||||
| 회전 설정 | 성공 | 이긴 토큰 재사용 | 남은 client session |
|
||||
|---|---|---|---|
|
||||
| revokeRefreshToken true · maxReuse=0 | 1 / 5 | 400 | 0 |
|
||||
| revokeRefreshToken false | 5 / 5 | 200 | 1 |
|
||||
| revokeRefreshToken true · maxReuse=1 | 2 / 5 | 400 | 0 |
|
||||
|
||||
회전을 끄면 경쟁 자체가 성립하지 않는다. 같은 refresh token 을 계속 쓸 수 있으니 다섯 다 200 이고 세션도 남는다. 대신 토큰이 유출되면 만료까지 계속 쓸 수 있고, 회전이 좁히려던 것이 바로 그 구간이다.
|
||||
|
||||
`refreshTokenMaxReuse` 를 1 로 올린 쪽은 절충이 되지 못했다. 성공이 1에서 2로 늘었을 뿐 남은 client session 은 0 그대로이고 이긴 토큰도 여전히 400 이다. 동시 요청이 N 개면 `refreshTokenMaxReuse` 가 N-1 이상이어야 한다는 계산이 여기서 따라 나오는데, 그러려면 몇 개까지 동시에 올지를 먼저 알아야 하고 그 답은 이 실험에 없다. N 을 바꿔 가며 재 보지도 않았으므로 이 계산은 두 구성에서 따라 나온 추론이다.
|
||||
|
||||
남는 길은 갱신을 직렬화하는 쪽이고, 그 잠금은 프로세스 밖에 있어야 한다 — 프로세스 안의 `synchronized` 는 replica 를 넘지 못한다. 후보로 PostgreSQL 행 잠금과 Redis 분산 lock 과 갱신 전용 인스턴스를 적어 두었지만 어느 것을 넣었을 때 이 재현이 사라지는지는 재지 않았다. 이 실험이 닫은 것은 무엇이 부서지는가까지다.
|
||||
|
||||
## 확인하지 않은 것
|
||||
|
||||
재시도 설계를 붙여서 다시 재지 않았다. 어떤 재시도가 이 상황을 복구하는지는 확인하지 않았다.
|
||||
|
||||
동시 요청 수는 5건 한 가지만 걸었다. 2건이나 20건에서 같은 결과가 나오는지는 세 구성 어디에서도 재지 않았다.
|
||||
|
||||
BFF 를 거쳐 같은 경쟁이 나는지도 재지 않았다. Keycloak 쪽 동작만 갈라 보려고 토큰 엔드포인트를 직접 쳤기 때문이다.
|
||||
<!-- body:end -->
|
||||
Reference in New Issue
Block a user