개발자 하민아빠의 Dev & Money

지금까지 우리는 상태 관리(Redux)와 라우팅(React Router)을 통해 클라이언트(화면) 단의 뼈대를 튼튼하게 다졌습니다.특히 지난 9편엔 새로 고침에도 로그인이 유지되도록 하는 reudx-persist를 알아보기도 했습니다. 이제 진짜 데이터를 화면에 뿌려주기 위해 백엔드 서버와 통신(API 호출)을 할 차례입니다.보통 API 통신에는 axios 라이브러리를 많이 사용하시죠?그런데 실무에서는 컴포넌트마다 axios.get()을 하드코딩하며 매번 로그인 토큰(Access Token)을 손으로 집어넣지 않습니다.귀찮기도 하고, 토큰이 만료되었을 때(401 에러) 대처하기가 너무 힘들거든요. 오늘은 모든 API 요청과 응답의 '문지기' 역할을 하는 Axios 인터셉터(Interceptor)를 알아보..

지난 글까지 프로젝트의 뼈대와 폴더 구조를 잡았습니다.이제 앱에 데이터를 흐르게 할 차례입니다.여러분은 API 통신을 어떻게 하고 계신가요?혹시 매번 API를 호출할 때마다 헤더에 토큰을 직접 넣어주거나, 토큰이 만료되었을 때 로그인 화면으로 튕겨 나가는 경험을 하진 않으셨나요?오늘은 현업에서 표준처럼 쓰이는 Dio 패키지를 활용해, 엑세스 토큰 자동 주입, 토큰 만료 시 자동 갱신(Refresh), 그리고 웹과 앱 환경을 모두 고려한 '프로덕션 레벨'의 네트워크 모듈을 만들어 보겠습니다.토큰 관련해서 흐름도를 알고 싶다면 이 글을 참고해주세요! 토큰이 탈취돼도 괜찮아? Access Token & Refresh Token 완벽 구현지난 2편을 통해 우리는 JWT의 구조에 대해 배웠습니다.하지만 JWT에는..

지난 포스팅에서는 Prisma와 RDB를 사용하여 RTR(Refresh Token Rotation) 시스템을 구현했습니다.지금까지 우리는 Prisma로 유저를 관리하고 Passport로 인증 로직을 구현했습니다.하지만 실무 레벨의 인증 시스템이 되려면 해결해야 할 두 가지 숙제가 남아있습니다.DB 부하 문제: Refresh Token처럼 빈번하게 쓰고 지워지는 데이터를 RDB에 저장해야 할까?보안 문제 (XSS): 토큰을 프론트엔드의 localStorage에 저장해도 안전할까?오늘 우리는 Redis를 도입해 DB 부하를 없애고, HttpOnly Cookie를 적용해 스크립트 공격(XSS)을 원천 봉쇄하는 방법을, 실제 t사이드 프로젝트의 서비스 코드를 기반으로 알아보겠습니다.1. Prisma Schema..

지난 포스팅까지 우리는 JWT Access Token을 발급하고 검증하는 기초적인 인증 시스템을 만들었습니다.하지만 실무에서는 Access Token 하나만으로는 부족합니다.유효기간이 짧으면 사용자가 불편하고, 길면 보안이 취약해지기 때문이죠.오늘은 이 딜레마를 해결하는 Refresh Token, 그중에서도 가장 보안 강도가 높은 RTR(Refresh Token Rotation) 방식을 구현해 보겠습니다.단순히 유저 테이블에 토큰 문자열 하나를 저장하는 방식이 아닙니다.별도의 토큰 관리 테이블을 두고, 사용된 토큰을 isRevoked (무효화) 처리하여 재사용 공격까지 완벽하게 방어하는 실무 레벨의 코드를 공개합니다.1. RTR(Refresh Token Rotation)이란?일반적인 Refresh Tok..

개발자로 일하다 보면 "이 부분은 Redis로 성능을 개선했습니다"라는 기술 블로그 글을 수없이 마주합니다.면접에서도 "Redis를 왜 사용하나요?"는 단골 질문이죠.사실 고백하자면, 현재 제가 몸담은 실무 환경에는 아직 Redis가 적용되어 있지 않습니다.하지만 내년부터 진행될 대규모 리팩토링 과정에서 Redis 도입이 예정되어있습니다.실무에 바로 투입되어 허둥대지 않으려면 철저한 준비가 필요하겠죠.그래서 저는 요즘 퇴근 후, 제 사이드 프로젝트에 Redis를 먼저 적용해 보며 '선행 학습'을 진행 중입니다.이 시리즈는 단순한 이론 정리가 아닙니다. "왜 이 기술을 써야 하는가?"에 대한 시니어 개발자의 고민과, 실무 도입을 준비하며 사이드 프로젝트에서 직접 검증한 아키텍처를 기록한 '실전 대비 노트'..

지난 2편을 통해 우리는 JWT의 구조에 대해 배웠습니다.하지만 JWT에는 치명적인 약점이 하나 있었죠."한 번 발급된 토큰은 서버가 강제로 만료시킬 수 없다."이 말은 즉, 해커가 여러분의 토큰을 훔쳐 가면 유효기간이 끝날 때까지 해커가 내 계정의 주인 행세를 할 수 있다는 뜻입니다.그렇다고 유효기간을 5분으로 줄이자니, 사용자가 5분마다 로그인을 해야 하는 최악의 경험을 하게 됩니다.보안(Security)과 사용자 경험(UX), 이 두 마리 토끼를 모두 잡기 위해 등장한 것이 바로 Access Token과 Refresh Token의 이중주입니다.1. 딜레마 해결: 유효기간을 쪼개자핵심 아이디어는 간단합니다."자주 쓰는 건 짧게, 가끔 쓰는 건 길게" 가져가는 것입니다.🎫 Access Token (출..

현 프로젝트에서 로그인 로직을 만들 때 AccessToken, RefreshToken 두 가지 토큰을 사용하는 방식으로, 그중 RefreshToken은 HTTP-Only Cookie의 형태로 주고받도록 설계했다.현 프로젝트 MSA 환경에서는 UI 서버의 도메인과 Gateway 서버의 도메인이 서로 달라서 SameSite 옵션을 반드시 'None'으로 설정해야만 했다.여기서 문제는 HTTP-Only Cookie는 SameSite = 'None'일 경우에는 반드시 secure = true로 해주어야 했다.즉 https 환경에서만 쿠키를 주고 받을 수 있는 것이다.개발서버와 양산서버는 당연하게도 https가 적용이 되어있어 구현 자체는 문제가 되지 않았다.그래도 로컬 환경에서 RefreshToken이 적용이 ..