2025. 3. 5. 16:31ㆍSpringboot/security
전체코드 : https://github.com/gks930620/spring_securty_all
JWT 를 이용한 토큰인증방식
JWT라는 거는 JSON Web Token의 약자로서 토큰의 하나의 형식 또는 종류라 할 수 있다.
토큰인증방식을 꼭 JWT를 쓸 필요는 없지만 JWT가 많이 쓰인다.
토큰인증방식은 다음과 같은 방식으로 진행된다.
1. 사용자가 로그인하면 JWT를 발급
2. 이후 요청마다 JWT를 HTTP Header에 포함 (Authorization: Bearer <토큰>)
3. 서버는 토큰을 검증하여 사용자를 인증
토큰인증방식이 필요한 이유
기존의 세션방식 말고 왜 토큰인증방식이 필요한가?
1. 서버확장성
세션방식은 사용자 수가 많아질수록 서버의 세션 메모리 부담이 증가하고
하나의 서버가 세션을 관리하는 세션방식에서 여러대의 서버로 확장하는 경우 세션관리를 위한
별도의 방법(세션 클러스터링 등)이 필요하게 됨.
토큰인증방식에서는 사용자가 많아져도 사용자가 토큰을 가지고 있기때문에 서버의 메모리 부담이 없음
또 서버가 여러개여도 서버는 토큰을 검증하기만 하면 됨.
2. API 서버와 클라이언트 분리
API서버와 클라이언트가 분리된 환경( React, Vue 등)에서 인증을 적용할 때
세션방식보다 토큰방식이 적합함.
(JWT 방식은 헤더방식이 때문의 브라우저의 CORS 쿠키정책 영향을 받지 않는 등)
또 API 서버가 분리되었기 때문에 웹 뿐만 아니라 모바일 앱, 외부API 서비스 등
여러 클라이언트에서도 인증을 쉽게 할 수 있음.
access token과 refresh token
기본적으로 토큰인증방식에서 JWT는 토큰의 형식,종류이다.
이 JWT를 가지고 토큰인증방식에서 access token 역할과 refresh token 역할을 부여한다.
access token은 username을 포함하고 있는 토큰으로서
클라이언트는 로그인 시도 시 access token을 획득한 후 (서버는 access token을 만든 후 응답)
매 요청마다 access token을 서버에 보내 인증된 사용자라는거를 알린다.
(서버는 매 요청마다 검사. username으로 매번 DB 조회)
access token은 기본적으로 30분의 만료기간을 갖는다.
refresh token은 access token을 재발급하는 용도로만 쓰이며 보통 7일 or 30일의 만료기간을 갖는다.
refresh token조차 만료된다면 클라이언트는 다시 로그인을 해야한다.
이 30분과 7일이라는건 보안과 사용자 편의성 간의 균형때문이다.
30분마다 재로그인을 하는건 불편, 그렇다고 7일동안 사용자 정보가 포함된 토큰을 사용한다면 보안위험.
(물론 access token이 탈취된 30분 동안은 위험함)
그래서 사용자 정보는 30분으로 제한하고 7일동안은 로그인을 보장하기 위한 refresh token을 병행하게 됨.
refresh token은 토큰인증방식의 statless 를 보완하기 위해 예외적으로
서버가 DB 등에 저장 + 클라이언트에도 저장함 (저장 방법은 클라이언트마다 다름) .
access token이 만료되었을 때
클라이언트는 refresh token을 다시 서버에 보내고 서버는 DB의 refresh token과 비교 후 갖다면
로그인 없이 다시 access token을 재발급 함
access token, refresh token 동작방식
로그인 시도
로그인 시도 후 인증된 사용자요청
클라이언트는 로그인 필요한 곳에 access token을 포함해 요청하게 된다.
access token 만료 후 요청.
클라이언트는 access token이 만료된 줄 모르고 access token을 가지고 요청한다.
서버는 access token 검사 후 만료됐다는 사실을 클라이언트에 전달한다.
refresh token 전달.
이후 클라이언트는 기존의 access token은 버리고, 새롭게 받은 access token으로 다시
인증된 사용자 요청을 하게 된다.
만료된 refresh token 전달
클라이언트는 refresh token가 만료된줄 모르고 refreh token을 가지고 access token 재발급을 시도한다.
서버는 클라이언트에게 refresh token이 만료됐다는 사실을 전달한다.
이후 클라이언트는 다시 로그인을 시도하면 된다.
클라이언트와 API서버
클라이언트와 API서버를 분리했을 때 서버는 각각의 요청에 맞게 잘 처리하면 되고
redirect 등을 통해 클라이언트가 어떻게 재요청하는지는 신경쓰지 않아도 된다.
서버입장에서는 위의 동작방식에서의 모든 요청을 각각 처리할 뿐이다.