리프레시 토큰을 왜 도입했을까?
현대의 웹 서비스들은 서비스의 사용자 인증을 위해서 다양한 방식이 사용됩니다. 많은 인증 방식 중 제일 많이 사용되는 방식은 JWT(Json Web Token) 인증 방식일 것입니다. 저희 서비스 역시 이 방식을 채택해서 인증 방식을 진행하고 있습니다.
Access Token만 이용한 인증 과정
1. 사용자 인증 요청: 사용자가 로그인 요청을 하면 서버는 사용자가 입력한 아이디와 비밀번호를 검증합니다.
2. 토큰을 생성하여 반환: 만약에 사용자가 입력한 아이디와 비밀번호가 일치한다면 서버는 토큰을 생성해서 클라이언트에 반환합니다. 이 토큰에는 여러 필요한 정보들을 담을 수는 있지만 보안에 민감한 정보들은 담지 않는 것이 좋습니다.
3. 클라이언트에서 토큰을 저장: 클라이언트는 서버로부터 받은 토큰을 보통은 로컬 스토리지에 저장합니다.
4. 사용자의 토큰을 포함한 요청: 이후 사용자는 요청을 보낼 때마다 3번에서 저장한 토큰을 요청 헤더에 포함시켜서 서버에 전송합니다.
5. 서버에서 토큰을 검증: 서버는 요청 헤더에 있는 토큰을 확인합니다. 만약 유효한 토큰이라면 요청을 처리하고, 그렇지 않다면 인증 예외를 발생시킵니다.
🤔 JWT는 안전할까? 그렇지만은 않다.
만약 해커가 토큰 정보를 탈취한다면 토큰의 Payload에 있는 정보들을 쉽게 확인하고 이용할 수 있습니다. 또한 위에서 보았듯이 토큰을 저장하는 주체가 클라이언트기 때문에 탈취를 당하더라도 서버 입장에서는 대응하기가 매우 어렵습니다.
Access Token과 Refresh Token의 등장
JWT는 좋은 장점들을 가지고 있는데 탈취당했을 때 대처하기가 어렵다는 이유만으로는 사용하지 않기가 매우 아쉽습니다. 때문에 등장한 개념이 토큰을 2개로 나누어서 인증 과정을 진행하는 방식으로 바뀌었습니다. 이 나눠진 2개의 토큰이 Access Token과 Refresh Token입니다.
Access Token
클라이언트가 요청을 보낼 때마다 같이 보내는 토큰입니다. 실제 인증 과정에서 쓰이는 토큰인 것입니다. 이 토큰에는 기본적으로 만료시간이라는 개념이 존재합니다. 만료 시간이 지난다면 해당 토큰이 더 이상 유효한 토큰이 아니게 됩니다. 이 토큰은 실제로 네트워크를 통해서 오기 때문에 탈취당할 위험이 있습니다. 그렇기 때문에 만료 시간을 짧게 설정하여 만약 탈취되더라도 토큰의 사용 가능 시간을 최소화해야 합니다.
Refresh Token
Access Token은 만료 시간이 짧습니다. 때문에 사용자가 자주 로그인을 다시 해야 하는 불편함을 초래할 수 있죠. 이 문제를 해결하기 위한 토큰이 Refresh Token입니다. Refresh Token은 Access Token이 만료되었을 때 Access Token을 재발급받는 데에 필요한 토큰입니다. Refresh Token의 만료 시간은 Access Token보다 길어야 합니다. 만약 Access Token보다 짧거나 거의 같다면 이 토큰이 존재할 이유가 없어집니다. 또한 Refresh Token은 서버에 저장됩니다. 왜냐하면 Access Token이 만료되었을 때 클라이언트는 Refresh Token을 보낼텐데 여기서 클라이언트가 보낸 Refresh Token과 비교할 수 있어야 되기 때문입니다.
🤔 서버에 Refresh Token을 저장한다면 무상태성의 장점이 사라지는 것이 아닌가?
아쉽지만 그렇습니다. 위에서 설명되었 듯이 Refresh Token은 Access Token의 만료 시간이 지난 이후에 Access Token의 재발급을 위해서 사용됩니다. 이 과정에서 서버에서는 클라이언트가 전송한 Refresh Token이 유효한 토큰인지를 검증할 수 있는 값이 존재해야 합니다. 그렇기 때문에 서버에 Refresh Token이 저장되어야 한다는 것입니다.
무상태성 상실과 사용자 경험 향상의 균형
많은 웹 서비스에서 JWT의 장점을 포기하더라도 Access Token과 Refresh Token을 같이 사용합니다. 아무래도 무상태성이라는 장점을 포기하면서도 사용자 경험 향상과 보안을 강화하는 것이 더 중요한 가치라고 생각하기 때문인 것 같습니다.