웹개발에서 jwt토큰 기반 인증 구현시 궁금한 점 질문드립니다 ㅠㅠ

Question

안녕하세요. 웹 풀스택 개발자를 목표로 공부를 하고 있는 완전 초짜 개발자입니다.JWT 토근 기반 인증 구현 시 풀리지 않는 의문점들이 있어 글 남깁니다.먼저 어떤 방식으로 설계할 것 인지에 대해 여러가지 검색 또는 AI로 찾아보니 크게 두 가지 방법 이있는거 같더라구요.AccessToken + RefreshToken 모두 JWT로 백엔드에서 응답해주는 방법(stateless)AccessToken은 백엔드에서 JWT로 생성 후 바디에 담아 응답해주고 프론트에서는 localStorage가 아닌 메모리에 저장하기.RefreshToken은 랜덤 문자열로 만들어 응답해주고 백엔드에서는 해시 처리해서 db에 저장(필요시 session테이블도 관리).RefreshToken은 보안 옵션 설정한 쿠키로 넣어주기.AccessToken이 만료되면 /refresh 요청으로 쿠키에있는 RefreshToken을 검증하고 새로운 AccessToken과 RefreshToken을 재발급 해주기.(RefreshToken 로테이션, db에 기존 refreshtoken revoke처리 및 새로운 refreshtoken 추가)./logout 요청 시 해당 refreshToken을 db에서 찾고 revoke처리 등 폐기 처리 후 refreshtoken이 담겨있는 쿠키 삭제.여기 2번 설계 방법에서 궁금증AccessToken을 프론트엔드에서 localStorage가 아닌 메모리에 자꾸 넣으라고 하는데 React 기준으로 state나 zustand등 변수에 담는 것인지? 그렇다면 새로고침 할때마다 AccessToken이 날라가 버리고 재발급을 위해 자동으로 /refresh요청이 수행되는데 만약 사용자가 로그인 후 마구마구 새로고침을 해버리면 /refresh 요청이 계속 수행되고 계속 db에 접근하게 됨. 이렇게 설계하는게 맞나요? 좀 이상하다고 생각이 들어가지고 질문남깁니다.만약 유효한 RefreshToken을 해커A가 탈취한 상황이라는 가정.사용자B는 인터넷 사용하다가 쿠키등 삭제 해버림. Accesstoken도 없고 Refreshtoken도 없으니 로그인 상태가 튕김(사용자는 로그아웃된 것처럼 인식). 하지만 백엔드 서버에서는 사용자의 refreshtoken정보를 알수가 없으니 db에 revoke등 폐기처리를 못해줌.그러면 해당 refreshtoken은 기간이 만료되기 전까진 DB에서 유효한 토큰으로 남아있음.해커A가 그 refreshtoken으로 /refresh 요청을 하여 새로운 Accesstoken과 refreshtoken을 재발급 받음(refreshtoken은 로테이션 해주니까). 이러면 해커가 영원히 갱신하면서 사용자B의 계정을 사용할수있는거 아닌가요?

커피한잔마시고1 · Accepted Answer

1번은 계속 새로고침 해버리면 일정 간격 단위로 api 요청하는 조건이 필요할 거 같습니다. 보통 nginx같은 앞단 서버에서 컨트롤 하면 될 거 같고요. 이렇게 구성하게 되면 내부 서버로의 접근을 미연에 방지하기 때문에 DB에 계속 접근하는 문제는 해결될 것 같습니다.2번은 방법이 여러가지 일 거 같은데, 떠오르는 아이디어는 네이버, 구글, 넷플릭스처럼 사용자가 처음으로 로그인하는 ip 환경에서는 휴대폰 인증(2차 검증)이 추가되면 해결될 것 같습니다. 아니면, refreshToken이 재발급 될 때 count하는 로직이 있다면 다른 사용자가 refreshToken을 재발급 하려고 하면 count가 2(유저가 1번 토큰을 발급받아서 1 카운트, 해커가 다시 그 토큰을 이용해서 발급 받으려고 하면 카운트 2)를 넘어가게 되고 이를 사용자에게 문자로 알려주는 로직도 고민해볼 수 있을 것 같습니다.

amiwho · Answer

짧은 지식이지만 도움이 될 것 같아 써요 1. 프론트엔드쪽은 잘 모르겠어요. Okky는 accessToken도 쿠키에 저장하고있어요. httpOnly인걸 보니깐 next나 nuxt같은 프론트엔드 서버에서 읽어서 하는 것 같아요refreshToken이 로테이션된다면 해커가 영원히 쓸 수 있는건 맞아요근데, 만약 사용자가 해킹을 인지하거나 이상 탐지 사례가 감지되거나 할 경우에 DB에 들어있는 리프레시 토큰을 지워버리면 /refresh가 안먹히겠죠이 경우에 DB에 저장되있지 않다면(완전 stateless라면), 대응할 방법이 제한되요.카드를 분실했으면, 습득한 사람이 마음대로 쓰는건 막을 수 없지만최소한 분실신고하면 결제가 안되게 하는거죠.

jj2e · Answer

1번a. 토큰을 body 로 응답 받는다? sessionStorage 정도에 저장하시면 됩니다.b. 서버에서 쿠키에 Set 한다. http-only 옵션, 검증도 서버에서 한다. 프론트는 안받아도 됩니다.2번. 아이디 비번 refreshToken 까지 털렸다면 비밀번호 초기화를 해야죠. 여기까지는 어쩔 수 없죠.

catcode · Answer

저는 JWT 할 때 AT는 쿠키에 HTTPONLY로 담아서 관리, 짧은 수명(대략 1시간 이내)RT는 DB에 저장, 긴 수명(1~3달 까지)으로 사용했었습니다. AT는 클라이언트, RT는 서버(DB)에서 관리하고 RT 만료시간 까지는 AT만 갱신해주는 방법 RT 탈취는 RT를 1인당 1개만 발급하게 하고 쿠키삭제로 인해 다시 로그인하면 이전 RT는 폐기처리, RT새로 발급 하면 되지 않을까요?(물론 사용성은 떨어집니다)

오후 · Answer

1번은 윗분들 댓글처럼 localstorage/sessionstorage/cookie등 여러방법이많고2번은 탈취 되었다는 가정상 생각 하신대로 RT이용 AT갱신해가면서 계속 이용 가능한 시나리오는 맞습니다. 그래서 해당부분은 추가적인 개발로 대응이 필요합니다 간단한 몇가지 방법으로 아래같은방법도 있습니다.중복 로그인 금지 : 정상사용자가 로그인시 - 기존 AT/RT 폐기처리중복 로그인 허용시 : 활성화된 로그인 정보 제공(기기등) > 로그아웃 처리

웹개발에서 jwt토큰 기반 인증 구현시 궁금한 점 질문드립니다 ㅠㅠ

5개의 답변

기술 목록