개발일지

Refresh Token이란?

Refresh Token은 Access Token과 마찬가지로 로그인을 할때 서버에서 발급해주는 jwt(json web token)이다

그렇다면 왜 로그인을 했을때 서버에서 2가지의 토큰을 발급 해 주는 것일까?

이 문제의 해답은 Access Token의 단점과 연결 된다.  

2021.08.02 - [Web] - JWT 지난 포스트에서 jwt의 단점 중 Access token을 발급하고 유효기간이 지나기 전 까지는 해커에게 토큰이 털려도 손 쓸 방법이 없다고 글을 작성했다. 그렇다면 "Access token의 유효기간을 짧게 하면서 문제를 해결 할 수 있는 방법이 없을까?"

라는 물음의 답이 바로 Refresh token인 것이다.

예를 들어 Refresh Token의 유효기간은 1주, Access Token의 유효기간은 1시간이라 생각해보자. 

사용자는 1시간동안 Access token을 이용하여 서버로부터 데이터를 받을 수 있으며 1시간이 지나면 다시 로그인을 하는 방식이 아닌 그 전에 발급 받은 refresh token으로 다시 Access token을 발급 받는 것 이다.

이런 refresh token의 장점은 Access token으로만 데이터를 주고 받는 서버에서 Access token의 유효기간을 줄이고 보다 더 안전한 사용이 가능하게 만들어 준다.

하지만 refresh token 또한 단점이 존재한다

일단 구현자체가 좀 복잡하고 refresh token을 어디에 저장해야 안전한지 (다음 포스트예약) 만약 refresh token을 탈취 당한다면 어떻게 해야할지 등 여러 문제가 있다.  

그럼에도 현재 로그인을 구현하는 가장 대표적이고 안전한 방식이 refresh token을 사용하는 것이라는 거에는 변함이 없다.

Refresh Token인증과정

1번부터 7번까지의 과정은 Access Token의 인증과정과 별 다를게 없다(refresh token을 함께 받아오는것 빼곤)

만약 Access Token의 유효기간이 만료가 되면 서버는 클라이언트에서 보낸 Access token의 유효기간이 지난 것을 확인하고 유효기간이 지났다고 응답한다. 그 다음 Access token의 재발급을 위해 클라이언트는 refresh token을 보내며 서버는 이를 확인 하고 Access token을 발급한다 

9~11의 과정은 프론트쪽에서 Access Token의 Payload를 통해 유효기간을 알 수 있어 유효기간이 끝나가는 시점에서 자동으로 Access Token을 재발급 받아주는 로직을 작성하면 된다.

참고

https://tansfil.tistory.com/59?category=475681 

JWT란?

Json Web Token의 약자로 모바일이나 웹의 사용자 인증을 위해 사용하며 인증에 필요한 정보들을 암호화시킨 토큰을 뜻한다!(토큰기반 인증방식)

https://jwt.io jwt사이트를 들어가 보게되면 암호화된 토큰을 볼 수 있는데 

토큰을 만들기 위해서는 크게 3가지, Header,Payload, Verify Signature가 필요하다!

Header : 위 3가지 정보를 암호화할 방식(alg 알고리즘 Verify Signature를 만드는 알고리즘이 들어감), 타입(jwt고정) 등이 들어감

Payload : 서버에서 보낼 데이터가 들어가며 일반적으로 유저의 고유 ID값, 유효기간이 들어간다

Verify Signature :  Base64 방식으로 인코딩한 Header,payload 그리고 SECRET KEY를 더한 후 서명된다.

최종적인 결과 : Encoded Header + "." + Encoded Payload + "." + Verify Signature

Header, Payload는 인코딩될 뿐(16진수로 변경), 따로 암호화 되지않는다. 따라서 누구나 디코딩하여 정보를 볼 수 있으며 Payload에 유저의 비밀번호같은 중요한 데이터가 들어 가면 매우 위험하다!

하지만 Verify Signature는 SECRET KEY를 알지 못하면 복호화할 수 없다!

예를 들어 사용자 A가 사용자 B의 정보를 훔쳐보고 싶어 Payload에 있던 A의 id대신 B의 id로 다시 인코딩한 후 받아온 토큰 값을 서버로 보냈다고 가정해보자.이때 서버에서는 Verify Signature 검사를 하게 되는데 Payload에 B의 id가 들어 있어도 A의 Payload로 기반으로 만들어진 Verify Signature때문에 유효하지 않은 토큰인 것 을 알 수 있다!결국 SECRET KEY를 알지 못하면 토큰을 조작 할수 없다는 것을 알 수 있다

JWT 인증방식

사용자가 로그인을 하면 서버에서는 DB에서 사용자가 맞는 지 확인 한 후 Access Token을 발급 하여 사용자에게 보내준다.

이렇게 로그인이 되고 사용자는 데이터를 요청하기위해 발급 받은 Access Token을 다시 서버로 보낸다. 그러면 서버는 Access Token값을 기준으로 판단하여 사용자가 맞는지 판다하고 요청하는 데이터를 응답해준다.

(장점)

1. 세션/쿠키는 별도의 저장소의 관리가 필요한것에 비해 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없어 간편하다.

이는 Stateless 한 서버를 만드는 입장에서는 큰 강점이다!

Stateless : 어떠한 별도의 저장소도 사용하지 않는, 즉 상태를 저장하지 않는 것을 의미한다

2. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하여 확장성이 뛰어남. (ex FaceBook,Google)

(단점)

1. 이미 발급된 JWT에 대해서는 돌이킬 수 없다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 된다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하여 한번 털리면 유효기간 끝날때까지 방법이 없다.

-->  해결책 : 기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급한다(다음 포스트 당첨)

2. Payload 정보가 제한적이다. 위에 말했던 이유인 Payload의 값은 누구나 디코딩이 가능하여 중요한 정보를 넣을 수 없다!

3. 세션/쿠키 방식에 비해 JWT의 길이는 길어 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생하게 된다!

참고 

https://tansfil.tistory.com/58?category=475681