1. Feedback + Q&A
question > 지금은 Spring Security JSESSION으로 로그인 하는데 JWT를 사용하는 게 좋을지 Redis를 세션 저장소로 사용하는 거로 수정하는 게 좋을지 고민이다.
answer > 여러 내용이라 찾아보고 더 추가하여 정리한 답변은 아래와 같다.
A. Spring Security에서 OAuth를 적용할 때의 흐름은 일단 아래와 같다.
1) 클라이언트가 OAuth 제공자(Google, Kakao, etc)에게 로그인 요청
2) OAuth 제공자가 Access Token 발급
3) 클라이언트가 발급받은 OAuth Access Token을 내 서버에 전달
4) 내 서버에서 OAuth Access Token 검증 후 사용자 정보 추출
5) 내 서버의 DB에 사용자 존재 여부 확인
5-1) 존재 시 해당 사용자 정보를 기반으로 JWT 발급(내 서버 인증용)
5-2) 존재하지 않으면 회원가입 처리 후 JWT 발급
6) 클라이언트에서 내 서버에서 발급한 JWT를 Authorization 헤더에 포함해서 요청 수행
B. JWT와 Refresh Token 관리 방식
Access Token은 클라이언트가 들고 있고 보통 HTTP Only Cookie나 Authorization 헤더에 가지고 있다.
Refresh Token은 클라이언트가 로컬 스토리지 또는 Redux에서 관리하고 보안이 중요하면 서버에 저장한다.
트래픽이 많아져서 부하가 생기면 Refresh Token을 Redis 또는 Memcached에 관리할 수도 있다.
C. 추가적인 설명
토큰은 사용자가 들고 있는 거고 서버 측에서 들고 있다면 레디스로 들고 있는 것이 맞다.
Oauth에서 주는 token은 내 인증을 위한 것이 아니라 내가 OAuth한테 보내기 위한 토큰이다.
이 때 filter를 걸어주는데 그 filter에서 Oauth 완료됐으니까 id 뽑아서 DB에 있는지 확인하고 JWT 토큰을 발급하는 것이다.
내 DB에 accessToken이나 refreshToken이 필수는 아니다.
보통 refresh token은 클라이언트에게 넘겨주고 local storage에 붙어 있게 한다, react는 redux에 넣는다.
D. 정리
정리하자면 내가 바꿀 로그인 과정은 아래와 같다.
OAuth 로그인 -> OAuth access token 발급 -> 내 서버에서 OAuth API로 사용자 정보(id, email)를 받아옴 -> 내 서버의 DB에서 해당 사용자 존재 여부 확인 -> 내 서버에서 JWT Access Token & Refresh Token 발급
그리고 Access Token은 30분 정도의 짧은 유효기간과 Refresh Token은 만료 시 새 토큰 발급에 사용하는데 7~30일로 설정하자.
Refresh Token은 Redis에 저장하여 탈취를 방지하자.
사용자가 API 요청시 Authorization에 Access Token 사용 시 내 서버에서 JWT 검증.
로그아웃 시 Redis에서 Refresh Token 삭제하자.
결국 JWT + redis로 하면 세션처럼 로그아웃 관리가 가능하다는 장점이 있고 로그아웃하기 전까지는 다시 OAuth 인증도 할 필요 없다.
그래서 정리하자면 JWT + redis로 변경하려고 한다.
자꾸 헷갈려서 정리하는 접은글이다.
JSESSIONID, JWT, Redis 조합을 어떻게 하는 게 좋을까 고민이다.

1. Redis 조회도 부담되나?
Redis는 메모리 기반(Key-Value) 저장소라서 일반적인 RDBMS보다 훨씬 빠르다.
하지만 트래픽이 많아지면 Redis 조회도 성능 부담이 될 수 있다.
Redis는 빠르지만, 요청마다 조회하는 방식(JSESSIONID + Redis)은 부하가 발생할 수 있음.
2. 그럼 JWT + Redis도 같은 거 아닌가?
JWT 기반 인증에서는 API 요청마다 Redis를 조회할 필요가 없다.
Access Token은 클아이언트가 가지고 있으며 서버는 JWT를 직접 검증한다.
Redis 조회는 오직 Refresh Token을 사용할 떄만 발생한다. 그래서 JSESSION + Redis보다 부담이 낮다.
3. JWT는 왜 빨라?
JWT는 세션 조회 없이 토큰만 검증하면 인증이 완료되므로 빠르다.
feedback > Spring Security filter가 없는데 인증 보내고 그럴 때 filter가 필요하다.
todo> 이 부분은 JWT + Redis 변경하면서 같이 바꾸려고 한다.
feedback > dockerfile에 버전명은 따로 관리하자, 태그명인데 버전을 일단 설정하고 관리하도록 하자.
result > 우선은 앱을 build할 때 버전을 관리하기 위해서 .env에 VERSION 변수를 생성하였다. 그리고 build.gradle에서 envFile을 읽어서 VERSION을 설정하도록 수정하였다.
# Version
VERSION=0.0.1
def loadEnv() {
def props = new Properties()
def envFile = file('.env')
if (envFile.exists()) {
envFile.withReader { reader -> props.load(reader) }
}
return props
}
group = 'com.fortuneApp'
def env = loadEnv()
def appVersion = env.getProperty('VERSION', '0.0.1-SNAPSHOT')
version = appVersion
그리고 도커에 fortune_app 이미지를 올릴 때는 태그명을 잘 입력해주자.
docker build --build-arg VERSION=0.0.1 -t fortune-app:0.0.1 .
feedback > @PatchMapping의 경우에는 data의 일부만 수정할 때 쓰고 Dto 전체를 받는다면, 심지어 validation도 하는 경우에는 Put을 쓰는게 맞다. 다 변경하자. Patch는 부분만 수정하고 통상적인 컨벤션(createdAt, updatedAt)을 제외한 것들을 수정할 때 사용한다.
result > 기존에 Patch 사용하던 부분 Put으로 전부 수정함.
3. CICD (빌드와 배포)
기본적으로 spring boot에서 source를 pull해서 받아오고 build를 하면 .jar가 생성된다.
.jar를 deploy해서 run을 하면 빌드에서 배포까지라고 표현한다.
pull(git) -> build(github action) -> jar (docker image build) -> deploy(docker hub upload) -> run (target 서버 = ec2 로그인까지)
크게 보면 github action에서 build에서 run까지 하는데 ec2 정보 넣어줘야 ec2 login console에 접근이 가능하다.
docker image pull 받아오고 run하는 것도 github action에 설정 가능하다.
3. TODO
- JWT + Redis로 수정하기
- EC2 인스턴스 만들고 docker 환경 설정하기 (사양 t3a.small + 퍼블릭 IP주소)
- health check api 만들어서 접근 IP 뽑는 API 만들어서 배포하고 테스트까지
- github actions를 잘 만들어보자
부가 설명
spring security 설정한 경우 /health에서 접근할 수 있도록 설정해줘야 한다.
보통 health check할 때 IP를 준느데 이 서버가 live한지 체크한다.
보통 ALB에 health check API가 있다. 이건 온프레미스 nginx 쓸 때 이야기고 cloud는 endpoint만 설정하면 알아서 체크한다.
그리고 보안을 누르면 인바운드 규칙이 있는데 특정 IP 대역대만 허용하고 싶으면 인바운드 규칙에 추가하면 된다.
아웃 바운드는 반대로 나가는 규칙인데 서버랑 연결할 DB 등을 설정한다.
터미널로 붙고싶으면 내 IP:포트22를 뚫어야한다. 0.0.0.0은 다 연다는 거다.
third party 먼저 올리고 서버 올리고 RDS 만들어서 쓰라고 하고 싶긴한데 비싸서 권장 안 한다.
목요일엔 ec2, 금요일엔 security를 정리하려고 한다.
'dev > 프로젝트' 카테고리의 다른 글
[프로젝트] Spring Security (2) | 2025.01.28 |
---|---|
[프로젝트] CICD (Github Actions, EC2, Docker, Putty, SSH) 적용 (9) | 2025.01.23 |
[프로젝트] Docker-Compose & Docker 적용 (7) | 2025.01.21 |
[프로젝트] On-Premise & Cloud (16) | 2025.01.21 |
[프로젝트] Redis & OAuth2 적용 (6) | 2025.01.21 |