---
kind: PROJECT_DECISION
slug: split-the-two-stores-and-design-each
title: 세션과 토큰의 저장소를 나눠 각각 설계한다
topic: where-application-state-lives
topicName: 세션과 토큰을 Redis 와 PostgreSQL 에 나눠 두기
project: keycloak-session-store
status: 게시 전
decisionStatus: ADOPTED
sourceRevision: cdac9b8178391311d8eca1ebc6cac15bb62d79af
source:
  - final/document.md#선택이-코드와-흐름에-반영되는-방식-b2
  - final/document.md#얻은-것-잃은-것-적용하지-않을-때-열린-질문-네-개에-대한-답
evidence:
  - ../../../final/evidence/raw/b1-redis-session-store__02-autoconfig-after.txt
  - ../../../final/evidence/raw/b2-multi-instance-session__01-jdbc-store-deploy.txt
  - ../../../final/evidence/raw/b2-multi-instance-session__02-schema.txt
  - ../../../final/evidence/raw/b2-multi-instance-session__03-plaintext-tokens.txt
  - ../../../final/evidence/raw/b2-multi-instance-session__04-overwrite-test.txt
  - ../../../final/evidence/raw/b2-multi-instance-session__05-logout-cleanup.txt
---

# 세션과 토큰의 저장소를 나눠 각각 설계한다

로그인 세션은 Redis 에, OAuth 토큰은 PostgreSQL 에 따로 두기로 했다. 한 저장소로 묶는 쪽을 먼저 시도했다가 세션만 옮겨지는 것을 보고 나눴다. 나눈 뒤에도 덮어쓰기와 로그아웃 정리는 풀리지 않았고 원인은 저장소가 아니라 기본키였다.

## 근거

- **세션과 인가된 클라이언트는 조회 키가 다르다**
  세션은 세션 id 로 찾고 토큰은 principal 이름으로 찾는다는 것이 나누기로 한 전제다.
- **세션만 Redis 로 옮기자 토큰이 따라오지 않았다**
  한 저장소로 묶는 대안을 실제로 적용해 보고 반쪽만 옮겨지는 것을 확인했다.
- **기본키에 세션 id 가 없어서 두 번째 로그인이 첫 토큰을 덮어썼다**
  나눠 옮긴 뒤에 무엇이 풀리고 무엇이 풀리지 않는지를 그 실험이 잰다.

## 결정문

Application Session 은 Redis 에 두고 OAuth2AuthorizedClient 는 JdbcOAuth2AuthorizedClientService 로 PostgreSQL 에 둔다. 두 저장소를 한 덩어리로 다루지 않고 각각 고른다.

인스턴스가 둘 이상이고 요청이 어느 쪽으로 갈지 모르는 구성에만 해당한다. 단일 인스턴스에서는 이 질문이 생기지 않는다.

## 판단 이유

아무것도 설정하지 않은 Spring Boot 애플리케이션에서 자동구성이 무엇을 고르는지 먼저 봤다. 토큰 쪽은 AuthenticatedPrincipalOAuth2AuthorizedClientRepository 가 잡혔고, 이 구현은 principal 이름으로 찾으므로 조회 키에 세션 id 가 없다. 세션 쪽은 세션 id 로 찾는다. 이름이 비슷한 두 개가 서로 다른 키로 굴러간다.

한 저장소로 묶는 쪽을 먼저 시도했다. SPRING_SESSION_STORE_TYPE=redis 로 Application Session 을 Redis 로 옮기고 빈 구성을 전후로 비교했더니 authorizedClientService, authorizedClientRepository, authorizedClientManager 셋 다 옮기기 전과 같았다. 세션 저장소를 바꿔도 OAuth2AuthorizedClient 는 따라오지 않는다.

그래서 토큰은 JdbcOAuth2AuthorizedClientService 로 PostgreSQL 에 따로 옮겼다. 이 문서가 Q3 에 낸 답도 같다 — "둘은 조회 키가 다르므로 각각 결정해야 한다. 세션을 Redis 로 옮겨도 토큰은 따라오지 않는다".

토큰 쪽 후보는 셋이었다. JdbcOAuth2AuthorizedClientService, Redis 로 직접 구현하는 것, 그리고 세션 안에 넣는 HttpSessionOAuth2AuthorizedClientRepository. 앞의 둘은 같은 인터페이스라 컨트롤러를 안 고쳐도 되지만, 둘 다 principal 이름으로 찾으므로 같은 사용자의 두 세션이 같은 행을 쓰는 것을 막지 못한다. 셋째는 Repository 쪽으로 바꿔야 하지만 세션 단위로 저장되므로 같은 사용자의 다른 브라우저가 서로를 덮어쓰지 않고, 그 대신 세션이 커진다. 셋째를 안 고른 것은 Q3 가 Redis 와 JDBC 중 무엇이냐를 물었기 때문이다. 그 대가가 아래 영향 절의 셋째와 넷째다.

## 영향

나눈 뒤 네 가지를 물었고 둘은 풀렸다.

다른 인스턴스로 요청해도 되는가 : 된다
재시작 후 로그인 유지 : 된다

이 두 항목은 B-2 의 검증 표에 적힌 판정을 옮긴 것이다. 증거 원문 다섯 개(배포 로그, 스키마, 평문 토큰, 덮어쓰기 시험, 로그아웃 정리) 어디에도 교차 인스턴스 요청이나 재시작 뒤 로그인을 확인한 출력이 없다. 표의 판정까지가 이 결정이 댈 수 있는 근거다.

나머지 둘은 저장소를 나눠도 풀리지 않았다.

같은 사용자의 다른 브라우저가 덮어쓰는가 : 덮어쓴다
로그아웃하면 두 저장소가 다 정리되는가 : 한쪽만

셋째와 넷째의 뿌리는 저장소 선택이 아니라 기본키 한 줄이다. JdbcOAuth2AuthorizedClientService 의 기본 스키마는 기본키를 이렇게 만든다.

PRIMARY KEY (client_registration_id, principal_name)

세션 id 가 이 키에 없어서 같은 사용자의 두 세션이 같은 행을 쓴다. 다른 브라우저로 다시 로그인하면 행이 늘지 않고 값만 바뀐다. 로그아웃한 뒤에는 Redis 세션이 0 키로 정리되고 PostgreSQL 토큰은 1 행으로 살아 있다. 그 행의 refresh token 은 평문이고, bytea 값을 디코드해 JWT 임을 확인했다.

저장소를 Redis 로 골랐든 PostgreSQL 로 골랐든 이 키가 같으면 결과도 같다. 이 결정은 두 문제를 안고 간다.

아직 하지 않은 것도 적어 둔다. 이 실험대는 원인을 기본키로 지목한 데서 멈췄고 스키마를 고쳐 본 적이 없다. 키를 바꾸면 덮어쓰기와 로그아웃 정리가 풀리는지, 평문 토큰을 어떻게 처리할지는 재 보지 않았다.