[개발] Next.js 13 JWT 재발급 (작성중)

Next.js 13 JWT 재발급

JWT는 개발 방법이 쉽고, 발급과 검증이 쉽기 때문에 개발자의 피로도가 줄었다고 생각한다.

하지만 JWT 또한 단점이 존재했다. 바로 보안성이다.

JWT 토큰은 따로 서버에서 관리하는 것이 아닌 토큰 값 자체로 이용하고 검증할 수 있다.

이 점은 Session과 다른 편리함을 불러왔지만, 역으로 생각해서 토큰만 탈취하면 너무나도 쉽게 보안 위험이 생기는 것이다.

 

그래서 저번 포스팅 JWT 발급에서는 토큰을 목적에 맞춘 두 가지로 나누어 발급하였다.

 

[개발] Next.js 13 JWT 발급 (tistory.com)

토큰 내용만 정리하면 다음과 같다.

토큰 종류	내용
accessToken	사용자 인증을 위한 토큰. 유효 기간을 짧게 설정하여 상대적으로 탈취되어도 덜 위험이 되도록 설계되었다. 보안을 생각하지 않은 단순한 사용자 인증을 위한 토큰이다.
refreshToken	accessToken 재발급을 위한 토큰. 유효 기간을 길게 설정하고, accessToken과 다르게 서버의 DB에 저장해둔다. 탈취되면 안되기 때문에 httpOnly, secure 설정의 쿠키로 전달될 것이다. 보안만을 위한 토큰이고, 사용자 인증은 전적으로 accessToken이 담당한다.

 

acessToken은 보안의 기능은 고려하지 않는다. 탈취 당하면 사용자를 위장할 수 있겠지만, 유효 기간을 매우 짧게 지정하여 탈취당해도 상대적으로 위험하지 않도록 설계했다.

refreshToken은 보안만을 고려한 토큰이다. 아무런 기능없이 단순히 accessToken을 재발급하는 기능이 되어야만 한다.

 

그렇다면 refreshToken은 어떻게 관리하고, 재발급 매커니즘은 어떤 식으로 작성해야할까?

우선 refreshToken 자체를 어떻게 관리 검증 해야할지 생각할 필요가 있다.

이 관리 방법에 대해서 세 가지 방법 중 고민하였다.

방법	장점	단점
1. verify 후 DB에 접근	두 번의 검증으로 보안성이 높아진다.	검증 및 DB 접근으로 성능이 떨어질 수 있음.
2. verify 후 payload 값 이용	DB 접근 소요없이 검증 및 값 이용 가능하다.	refreshToken에 대한 관리 규칙 및 내용이변하면, 이전 사용자들에 대한 토큰 관리 불가능. ( 확장성 떨어짐 )
3. DB 값만 이용	확장성이 높고, 직접 관리하므로 보안성 높음.	DB 접근으로 성능이 떨어질 수 있음. 또한 검증이 된 토큰은 아님.

 

나는 1번 verfiy 후 DB 접근 을 고르도록 하였다.

이유는 refreshToken은 오직 보안만을 위한 토큰이기 때문에 보안성이 가장 중요하다고 생각하기 때문이다.

 

재발급 매커니즘은 다음 두 가지 방법 중 고민하였다.

방법	장점	단점
1. 미들웨어로 재발급	추가적인 호출 필요 없음.	미들웨어 로직이 복잡해질 수 있음.
2. 재발급을 위한 API 작성	기능을 분리하여 코드를 간결하게 정리 가능.	API 요청이 추가적으로 필요함.

 

이 방법은 1번 미들웨어로 재발급 을 고르도록 하였다.

이유는 저번 프로젝트때 API 요청이 많아서 브라우저 성능이 떨어지고, 서버 소요가 늘어난 경험이 있었기 때문이다.

그래서 API 요청 횟수를 줄이고 싶었다.

또한 1번 방법으로는 요청이 왔다갔다 해서 여러 번의 로직을 관리할 필요없이,

한 번의 요청 로직으로 코드 흐름이 명료해지기 때문에 해당 방법을 선택하였다.

 

추가적으로 accessToken은 별도의 응답이 아닌, 기존의 응답에 추가적으로 accessToken을 포함시키도록 하였다.

 

결론

JWT 재발급은 여러가지 구현 방법이 있어서 고민됐었다.

위와 같은 매커니즘들을 고민하고, 나름대로의 논리로 결정한 내용은 다음과 같다.

 

• refreshToken은 verify 후 DB 접근

추가적으로 refreshToken을 DB에 저장시키는 소요가 필요하다.

 

• 미들웨어로 재발급

Next.js 13 의 middleware.ts로 로그인 토큰이 필요한 모든 요청이 통할 수 있도록한다.

 

백엔드 코드

• tokens.model.ts
• middleware.ts

 

프론트엔드 코드

• easyFetch.ts

 

 

결과

JWT로 로그인을 구현하는 것은 빠르고 편하다 !

하지만 JWT를 사용하는 것에 대한 보안 문제에 대한 시각은 언제나 존재하는 것 같다.

accessToken 만료 시간을 짧게하고 refreshToken을 둔다면 나름 보안적인 문제도 해결되는 것 처럼 보인다.

하지만 여전히 유효기간 내에 탈취된다면 보안 문제가 발생할 수 있다는 문제가 있는 것 같다.

 

또한 refreshToken을 서버에 저장하고, accessToken을 재발급하는 구조는 기존 Session으로 인증 하는 것과 소요적인 이득이 있는가? 라는 의문이 들기도 한다.

 

이 부분에 대해선 더 공부해봐야하고, 추후에 리팩토링을 진행할 수 있다면 해보고 싶다 ㅎㅎ