출처 : https://www.rfc-editor.org/rfc/rfc6749.html
access token과 refresh token
로그인을 할때 매번 비밀번호를 입력할 필요가 없이 브라우저의 쿠키에 액세스 토큰이 저장되어 로그인되게 하는 기능을 구현하였다.
최초 로그인시 서버에서 액세스 토큰을 발급해주고 클라이언트로 보내준다. 그러면 브라우저는 토큰을 로컬 스토리지나 쿠키에 저장한다. 그 이후 로그인부터는 이 토큰을 서버로 보내고, 서버가 검증한 다음 맞으면 로그인시켜주는 것이다.
그러나 액세스 토큰은 탈취 위험성 때문에 유효기간을 짧게 가져간다. 리프레시 토큰은 액세스 토큰이 만료 시간이 지난 후에 액세스 토큰을 갱신하기 위해 사용하는 토큰이다. 프로젝트 목표에 리프레시 토큰 구현까지는 있지 않았지만 공부해보며 구현해보고 싶은 욕심에 리프레시 토큰까지 구현하였다.
JWT라는 라이브러리를 사용하며 토큰을 만들 수 있다. JWT는 Json web token의 약자로 암호화되어 header, payload, signature로 이루어진다.
refresh token의 작동방식
리프레시 토큰은 액세스 토큰을 갱신해준다는 기능은 동일하지만 리프레시 토큰을 어디에 저장할 것인가 하는 것에 관해서는 여러 방법이 존재한다.
리프레시 토큰을 아예 DB에 저장하는 법, 클라이언트에 주는 경우 로컬스토리지에 주는 법, 쿠키에 http only 옵션으로 주는 법 등이 있다. 로컬 스토리지에 저장하는 것은 쿠키에 저장하는 것보다도 보안이 떨어진다. 매우 쉽게 탈취 될 수 있다. DB에 저장하는 법은 웹에 많은 예제가 나와 있지만 그렇게 하면 안된다는 반대 정보도 많았다. 리프레시 토큰을 쓰는 전략은 매우 다양한데 아직까지는 통일된 하나의 대세라고 할만한 방법은 없는 것같다.
스택오버플로우에서는 http only 속성으로 쿠키에 저장하는 것을 권장한한다.
개인적으로는 리프레시 토큰을 클라이언트에게 주지 않고, DB에만 저장했다가 액세스 토큰이 만료되었다면 DB에서 리프레시 토큰을 가져와서, 그것을 검증해서 액세스 토큰을 만드는 방식을 취한다면, 굳이 리프레시 토큰을 사용하는 의미가 없지 않나? 하는 생각이 들었다. 이 방식이 그냥 액세스 토큰의 만료 기한을 늘리는 것과 무슨 차이가 있을까? 그렇게 하면 이건 리프레시 토큰이 아니라 액세스 토큰을 만들기 위한 키에 불과하지 않은가?
토큰은 클라이언트가 서버에게 제시해서 권한을 있는지 없는지를 판별하는 것인데 이 본질이 뒤바뀌는 것 같았다. 물론 DB에 저장해서 얻는 이점도 있겠지만 짧은 프로젝트 기간 중 내가 파악한 지점은 이것이다.
나는 쿠키에 http only 옵션을 줘서 저장하는 방식으로 리프레시 토큰을 구현했다.
액세스 토큰의 만료기한은 하루, 리프레시 토큰의 만료기한은 1주로 했다.
