직접 로그인 구현하기

로그인을 직접 구현하면서 발생한 문제점을 정리해보겠다.

먼저, JWT 를 사용해 로그인을 구현하기로함

이유: 세션은 스케일아웃이 어려움, 쿠키에 user table의 pk 값만 담아도 충분함

엑세스 토큰, 리프레시 토큰을 어디에 두어야 하는가

• 검색해보니 블로그마다 구현한 방식이 다름

• 액세스 토큰은 일반 쿠키에 담자 - 보안에 좋지 않다. 그러므로, 유효시간을 짧게 둔다.

• 리프레시 토큰은 http only, secure, samsite=lax 쿠키에 담자 - 쿠키 중 가장 안전한 방식

Q. 그런데, 액세스 토큰 자체를 리프레시 토큰처럼 안전한 쿠키에 보관하면 되는것 아닌가?

A. 그래도 보안에는 차이가 없지만, 액세스 토큰을 일반 쿠키로 두었을 때, next.js 와 같이 클라이언트와 백엔드 사이에서 쿠키를 사용할 일이 생기면 http only 쿠키는 중간에서 사용할 수 없다.

(수정) 도메인이 같다면 백엔드, next 서버 모두 쿠키를 사용할 수 있다. 따라서 액세스 토큰도 안전한 쿠키에 저장해도 된다.

그럼 리프레시 토큰은 절대 안털림?

• 절대 안털린다고는 당연히 말할 수 없다. 완벽한 보안이 존재하면 아무도 고민 안할듯

• 그래서 리프레시 토큰도 털릴 경우를 대비하면 좋다.

RTR

• RTR 방식을 사용해서 리프레시 토큰이 털리는 것을 어느정도 방지해줄 수 있다.

• RTR은 처음 로그인 시 엑세스, 리프레시 토큰을 발급받고, 이후 액세스 토큰이 만료되면 리프레시 토큰을 사용해 새로운 리프레시, 액세스 토큰을 발급받는 방식이다.

• 이전에 발급된 리프레시 토큰은 쓸모가 없어진다.

• 자연스럽게 유저가 계속 서비스를 사용하면, 로그인이 영원히 유지된다.

시나리오

1. 액세스토큰만 털어간다

   1. 30분 정도는 유저인척 할 수 있다.

   2. 이후 액세스 토큰 만료 시, 리프레시 토큰이 없기에 더이상 유저인척 할 수 없다.

2. 액세스토큰, 리프레시 토큰 둘다 털어간다.

   1. 마찬가지로 30분 정도 유저인척한다.

   2. 이후 액세스 토큰 만료되면,

      1. 해커가 먼저 새로 발급받는다. -> 유저가 이후에 다시 로그인해, 새로운 리프레시, 액세스 토큰을 발급받고, 해커의 리프레시 토큰을 무효화 시킨다.

      2. 유저가 먼저 새로 발급받는다. -> 해커의 리프레시 토큰이 무효화된다.

물론, 리프레시, 액세스 토큰이 털렸는데 유저가 로그인을 하지 않는다면 해커는 영원히 유저인 척 할 수 있다.