[사이드 프로젝트] AccessToken 재발급 API 설계기

개요이 글은 지난 글에서 정리한 RefreshToken 상태 관리 흐름을 기반으로, AccessToken 재발급 API를 어떻게 설계했는지를 기록한 글이다.AccessToken은 보안상 수명이 짧아야 한다. 왜 그럴까?한 번 발급된 AccessToken이 탈취되면, 서버 입장에서는 그 토큰이 "정상 유저"의 것인지, "공격자"가 훔친 것인지 구분할 방법이 없다.즉, 토큰 탈취는 매우 치명적인 보안 위협이다.하지만 만약 AccessToken의 수명을 짧게 가져간다면? → 탈취되더라도 사용 가능한 시간 자체가 짧아진다.이는 AccessToken이 탈취되었을 때의 피해를 최소화하기 위한 가장 현실적이고 안전한 설계 전략이다.따라서 이 글에서는, "짧은 수명"을 갖는 AccessToken을 어떻게 ..

• format_list_bulleted 개발
• · 2025. 4. 15.
• textsms

[사이드 프로젝트] RefreshToken은 상태다 — Redis를 활용한 인증 흐름 제어

개요JWT는 Stateless한 인증 구조를 만든다.하지만 그 JWT의 지속성(Persistence)을 보장하기 위해우리는 RefreshToken을 함께 사용한다. 이 글은 그 RefreshToken을 어떻게 안전하게 관리할지,특히 왜 Redis를 선택하게 되었는지를 설명하는 글이다. RefreshToken은 왜 필요할까?AccessToken은 보안상 수명이 짧다.→ 탈취되었을 때 피해를 최소화하기 위해. 하지만 사용자가 매번 로그인하는 건 불편하다.→ 그래서 등장한 것이 RefreshToken이다. 즉, RefreshToken은 AccessToken의 수명 보완 장치다. Stateless한 JWT 안에 있는 “상태”의 아이러니JWT는 인증 정보를 담은 Self-contained Token이다.→..

• format_list_bulleted 개발
• · 2025. 4. 14.
• textsms

[사이드 프로젝트] 컨트롤러에 인증 로직이 없다면? 커스텀 어노테이션 설계기

개요JWT 인증이 완료된 사용자 정보를 컨트롤러 파라미터에 깔끔하게 주입하는 방법은 없을까?JWT에서 `userId`를 꺼내는 코드가 매번 서비스단, 컨트롤러단에 흩어지는 걸 보며 "이건 진짜 가독성이 너무 떨어진다"는 생각을 했다.그래서 시작된 것이 바로, 커스텀 어노테이션 `@LoginMember` 구현이다. 문제 인식) 컨트롤러가 너무 지저분하다JWT 인증 시스템을 직접 구현하고 나니, 컨트롤러에서 이런 코드가 자주 등장했다Long memberId = jwtTokenProvider.extractUserIdFrom(request.getHeader("Authorization"));매번 헤더 파싱서비스에서 또 JWT 검증 호출테스트 코드에서 매번 이 흐름을 신경 써야 함→ 분명 한 번만 해결..

• format_list_bulleted 개발
• · 2025. 4. 14.
• textsms

[사이드 프로젝트] JWT는 왜 Stateless한가?

개요"JWT는 Stateless한 인증 방식이다."처음 이 문장을 봤을 때, 고개를 갸웃했다. "왜 Stateless지? 토큰을 쓰면 상태가 있는 거 아닌가?" 의심에서 시작된 질문은 결국,JWT 기반 인증 시스템을 내가 직접 설계하게 만들었다. 이 글은 그 설계 흐름을 따라가며왜 JWT가 Stateless한 인증 구조를 가능하게 해주는지,그리고 그 구조 안에서 어떤 요소들을 고민해야 하는지 정리한 기록이다. 기존 세션 기반 인증의 한계세션 방식은 인증 정보를 서버에 저장한다.사용자 로그인이 완료되면, 서버는 유저 정보를 메모리나 DB에 저장하고,클라이언트에 세션 ID만 전달한다. 문제는 서버가 상태를 기억해야 한다는 점이다.서버가 꺼지거나, 스케일 아웃 구조일 경우 상태 공유가 필요하다부하 분산이 ..

• format_list_bulleted 개발
• · 2025. 4. 14.
• textsms

[사이드 프로젝트] Redis는 TTL 때문에 쓰면 과한가?

개요"TTL 하나 때문에 Redis 쓰는 건 좀 과한걸까?" 이 질문은 이번 사이드 프로젝트에서 인증번호 발송 기능을 구현할 때 실제로 던졌던 물음이었다. Redis는 워낙 빠르고 강력한 도구지만, 반대로 비용과 복잡도를 높이는 도구이기도 하다. 그래서 나는 정말 이게 "단지 TTL만을 위해 쓰는 것"인지,아니면 "설계적으로 필요한 선택"인지를 깊게 고민했다.이 글은 그 고민의 흐름과 결론을 정리한 글이다. 어떠한 기능에 Redis를 쓰려 하는가?내가 구현하려는 기능은 회원가입 시 휴대폰 인증번호 발송 및 확인 기능이었다. 기본 흐름은 아래와 같다0. 약관 동의1. 사용자가 인증번호 요청2. 서버가 인증번호를 생성해 저장 (유효시간 3분)3. SMS 발송4. 사용자가 인증번호 입력5. 서버가 ..

• format_list_bulleted 개발
• · 2025. 4. 14.
• textsms

[사이드 프로젝트] QueryDSL과 타입 안정성을 고려한 커서 설계기

개요이 글은 이전 글 "정렬 하나에도 설계가 들어간다"의 연장선이다. Offset 기반 정렬 구조에서 성능 한계와 유지보수성 문제를 마주했고,이를 개선하기 위해 Keyset 기반 커서 방식으로 구조를 리팩토링하게 되었다.특히 QueryDSL 기반의 동적 쿼리 생성과타입 안정성을 보장하는 범용 커서 설계를 어떻게 구현할 수 있을지에 대해 집중했다. 이 과정에서 필자는 스스로에게 다음과 같은 질문을 던지게 되었다:다중 정렬이 필요하다면, 커서 값은 어떻게 쿼리에 반영되어야 할까?커서 값이 동일한 데이터가 여러 개인 경우, 중복 조회 문제는 어떻게 해결할 수 있을까?커서 방식의 동적 쿼리를 어떤 책임 단위로 나누는 것이 좋을까?QueryDSL 쿼리 구조와 정렬 기준을 어떻게 추상화할 수 있을까?커서 타입이 다..

• format_list_bulleted 개발
• · 2025. 4. 11.
• textsms