
배경사용자가 인증을 완료하면 서버는 Access 토큰과 Refresh 토큰을 발급한다. 이후 사용자가 로그아웃하면, 해당 토큰을 Blacklist에 등록하게 된다. 이후 사용자가 토큰을 포함해 서버에 요청을 보낼 경우, 서버는 해당 토큰이 유효한지 검증하고 동시에 Blacklist에 등록된 토큰인지도 확인하게 된다. 이러한 흐름에서 토큰의 Blacklist를 Redis와 같은 in-memory DB에서 관리해도 괜찮을지에 대한 의문이 들었고, 이에 대한 고민과 실험 내용을 정리해보았다. 본문Redis는 휘발성이다?Redis is the world’s fastest in-memory database.. (Redis 공식 문서) Redis 공식 문서에서도 알 수 있듯이 Redis는 메모리에 데이터를 ..
배경나는 사용자 인증 관리를 JWT로 구성했었다. 그 배경에는 세션이 멀티 서버 환경에서는 중간 미들웨어가 있어야 한다는 단점이 있었기 때문이다. (물론 Sticky Session을 활용한다면 미들웨어를 사용하지 않아도 되지만 멀티 서버의 장점을 발휘하지 못하기 때문에 고려하지 않았다.)하지만 팀원이 캐싱 관리를 위해 Redis를 도입하게 되면서 Redis 활용이 가능해졌고 이러면 사용자 인증 관리를 Redis + 세션을 활용한 방식으로도 구성이 가능해졌다.그래서 기존의 JWT 방식을 유지할지, 하니면 JWT를 제거하고 세션을 활용하는 방식으로 사용자 인증을 관리할지 다시 고민하게 되었다. 고민확장성JWT는 사용자 식별 정보를 토큰에 담아서 헤더에 넣어주기 때문에 Stateless 구성이 가능하다. ..
- Total
- Today
- Yesterday
- 스프링 api 테스트
- 토큰 블랙리스트
- 게임개발
- 우테코 준비
- 우테코 6기
- 우아한테크코스
- 레디스 분산락
- 파이썬
- 환경변수 관리
- 스왑 메모리 장단점
- 자바
- 우테코
- JWT
- 우아한테크코스 후기
- contextwith
- gcp 인바운드
- 우아한테크코스 6기
- 우아한테크코스 자소서
- 6기
- setnx
- 스왑 메모리 설정
- sh 문법 오류
- redis
- 우테코 프리코스
- 코루틴
- 토큰
- 알고리즘
- redis 메모리 사용량
- Assertions
- 레디스
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |