들어가기 앞서..
JWT를 이용한 로그인을 구현하는 예제를 해보다, AccessToken과 RefreshToken을 구분해서 사용하는 이유와 정확한 개념을 이해하고 싶어 찾아보게 되었다. 다들 refreshToken을 사용하는 이유는 더 높은 보안성을 유지하기 위해서라고 알고 있을 것이다. 이번 기회를 통해 더욱 자세히 알아보겠다.
RefreshToken 을 사용하는 이유?
RefreshToken을 사용하는 이유를 설명하기 앞서, 우선적으로 AccessToken만을 사용할 때의 문제점을 설명하겠다.
AccessToken만을 사용할 때의 문제점은 무엇일까?
1. 사용자의 잦은 로그아웃으로 인한 불편함
AccessToken을 설정할 때, 유효 시간을 지정할 수 있다. 해당 기간은 개발자 마음대로 지정이 가능하다. 만일 유효 시간을 1시간으로 지정했다고 가정해보자. 그렇게 된다면 사용자는 해당 서비스를 이용할 때, 1시간이 지나게 되면 요청 시, 만료된 Token을 서버에서 감지하고 로그아웃을 하게 할것이다. 그렇게 되면 사용자는 매 1시간마다 로그인을 새로 해줘야 하는 불편함이 생기게 된다.
그렇다면 유효기간을 길게하면 되지 않나? 라고 생각할 수 있다. 유효기간을 길게 하면 보안문제가 발생할 수 있다.
2. 보안 취약
위에서 말한것처럼, 사용자의 불편함을 최소화하기 위해서 유효기간을 길게 설정했다고 가정해보자. JWT를 사용해서 구현한 AccessToken의 경우, Session 방식과 다르게 stateless 한데, 이는 쉽게 말하면 개발자가 관리하는 DB에 저장이 되는 방식이 아니라는 뜻이다.
만약 해당 Token을 누군가가 탈취하게 된다면 어떻게 될까? 유효기간이 끝날때까지 탈취된 Token으로 마음대로 요청을 하게될 수 있다. 이는 치명적인 보안의 문제점을 가져다 주게 된다. 개발자가 해당 Token이 탈취된 사실을 알게 되어도 직접 관리하는 DB에 저장된 방식이 아니기에, 유효기간이 만료될 때 까지 속수무책 당할 수 밖에 없다.
-> 위의 이러한 문제들을 해결하고자 RefreshToken을 사용하는 것이다.
Refresh Token?
RefreshToken의 목적은 AccessToken의 유효기간을 아주 짧게 설정하여, 자주 재발급 받도록 하여서 앞서 설명한 문제점들인 잦은 로그아웃 문제, 보안 취약 문제를 해결하기 위함이다.
즉, AccessToken이 만료 되었을 때, RefreshToken을 확인하여 새로운 AccessToken을 재발급 해주는 기능이다.
주로 AccessToken은 30분 이내, RefreshToken은 2주 이내, 정도로 기간을 설정하는 편이다.
Refresh Token Process
- 클라이언트가 로그인에 성공하면, 서버에서 AccessToken과 RefreshToken 을 넘겨준다.
* 이때, 두 Token은 다른 값을 할당해주는 것이다. - 로그인에 성공한 클라이언트는, 이후 요청시마다 Header에 AccessToken을 함께 넣어 보낸다.
- 요청시, 만약 AccessToken이 만료된다면, RefreshToken을 서버로 전달하여 새로운 AccessToken을 재발급받고, 다시 요청한다. (경우에 따라, RefreshToken을 재발급 해주도록 설정도 해줄 수 있다.)
Refresh Token의 형태
앞서 RefreshToken은 무조건 JWT로만 설정해서 사용하는 줄 알았지만, 찾아보니 문자열이나 UUID와 같은 형태로도 사용이 가능하다는 것을 알게되었다. 이러한 경우들의 장단점을 살펴보겠다.
Refresh Token - JWT
RefreshToken을 AccessToken과 동일하게 JWT로 설정해준다면, stateless하게 되고 Token에 데이터를 담을 수도 있다. DB에 직접 저장하는 방식이 아니기에, 서버의 부하도 적을 것이도 속도 측면에서도 효율적일것이다.
하지만, DB에 저장하는 방식이 아니기에 직접 제어할 수 없다는 단점이 존재한다. 만약 RefreshToken을 탈취당하게 된다면, 개발자가 무효화 시킬 수 있는 방법이 없는 것이다.
Refresh Token - Not JWT
RefreshToken을 문자열 또는 UUID와 같은 값으로 사용하게 된다면, 해당 Token을 사용자와 매핑해서 DB에 저정할 것이다. 이러한 경우는 앞서 JWT를 사용할때의 단점인, Token 탈취 시 직접 무효화 할 수 있어 보안이 좀 더 강화될 수 있다. 하지만, DB에 직접 접근해야 한다는 것은 속도 측면은 단점으로 볼 수있다.
들어가기 앞서..
JWT를 이용한 로그인을 구현하는 예제를 해보다, AccessToken과 RefreshToken을 구분해서 사용하는 이유와 정확한 개념을 이해하고 싶어 찾아보게 되었다. 다들 refreshToken을 사용하는 이유는 더 높은 보안성을 유지하기 위해서라고 알고 있을 것이다. 이번 기회를 통해 더욱 자세히 알아보겠다.
RefreshToken 을 사용하는 이유?
RefreshToken을 사용하는 이유를 설명하기 앞서, 우선적으로 AccessToken만을 사용할 때의 문제점을 설명하겠다.
AccessToken만을 사용할 때의 문제점은 무엇일까?
1. 사용자의 잦은 로그아웃으로 인한 불편함
AccessToken을 설정할 때, 유효 시간을 지정할 수 있다. 해당 기간은 개발자 마음대로 지정이 가능하다. 만일 유효 시간을 1시간으로 지정했다고 가정해보자. 그렇게 된다면 사용자는 해당 서비스를 이용할 때, 1시간이 지나게 되면 요청 시, 만료된 Token을 서버에서 감지하고 로그아웃을 하게 할것이다. 그렇게 되면 사용자는 매 1시간마다 로그인을 새로 해줘야 하는 불편함이 생기게 된다.
그렇다면 유효기간을 길게하면 되지 않나? 라고 생각할 수 있다. 유효기간을 길게 하면 보안문제가 발생할 수 있다.
2. 보안 취약
위에서 말한것처럼, 사용자의 불편함을 최소화하기 위해서 유효기간을 길게 설정했다고 가정해보자. JWT를 사용해서 구현한 AccessToken의 경우, Session 방식과 다르게 stateless 한데, 이는 쉽게 말하면 개발자가 관리하는 DB에 저장이 되는 방식이 아니라는 뜻이다.
만약 해당 Token을 누군가가 탈취하게 된다면 어떻게 될까? 유효기간이 끝날때까지 탈취된 Token으로 마음대로 요청을 하게될 수 있다. 이는 치명적인 보안의 문제점을 가져다 주게 된다. 개발자가 해당 Token이 탈취된 사실을 알게 되어도 직접 관리하는 DB에 저장된 방식이 아니기에, 유효기간이 만료될 때 까지 속수무책 당할 수 밖에 없다.
-> 위의 이러한 문제들을 해결하고자 RefreshToken을 사용하는 것이다.
Refresh Token?
RefreshToken의 목적은 AccessToken의 유효기간을 아주 짧게 설정하여, 자주 재발급 받도록 하여서 앞서 설명한 문제점들인 잦은 로그아웃 문제, 보안 취약 문제를 해결하기 위함이다.
즉, AccessToken이 만료 되었을 때, RefreshToken을 확인하여 새로운 AccessToken을 재발급 해주는 기능이다.
주로 AccessToken은 30분 이내, RefreshToken은 2주 이내, 정도로 기간을 설정하는 편이다.
Refresh Token Process
- 클라이언트가 로그인에 성공하면, 서버에서 AccessToken과 RefreshToken 을 넘겨준다.
* 이때, 두 Token은 다른 값을 할당해주는 것이다. - 로그인에 성공한 클라이언트는, 이후 요청시마다 Header에 AccessToken을 함께 넣어 보낸다.
- 요청시, 만약 AccessToken이 만료된다면, RefreshToken을 서버로 전달하여 새로운 AccessToken을 재발급받고, 다시 요청한다. (경우에 따라, RefreshToken을 재발급 해주도록 설정도 해줄 수 있다.)
Refresh Token의 형태
앞서 RefreshToken은 무조건 JWT로만 설정해서 사용하는 줄 알았지만, 찾아보니 문자열이나 UUID와 같은 형태로도 사용이 가능하다는 것을 알게되었다. 이러한 경우들의 장단점을 살펴보겠다.
Refresh Token - JWT
RefreshToken을 AccessToken과 동일하게 JWT로 설정해준다면, stateless하게 되고 Token에 데이터를 담을 수도 있다. DB에 직접 저장하는 방식이 아니기에, 서버의 부하도 적을 것이도 속도 측면에서도 효율적일것이다.
하지만, DB에 저장하는 방식이 아니기에 직접 제어할 수 없다는 단점이 존재한다. 만약 RefreshToken을 탈취당하게 된다면, 개발자가 무효화 시킬 수 있는 방법이 없는 것이다.
Refresh Token - Not JWT
RefreshToken을 문자열 또는 UUID와 같은 값으로 사용하게 된다면, 해당 Token을 사용자와 매핑해서 DB에 저정할 것이다. 이러한 경우는 앞서 JWT를 사용할때의 단점인, Token 탈취 시 직접 무효화 할 수 있어 보안이 좀 더 강화될 수 있다. 하지만, DB에 직접 접근해야 한다는 것은 속도 측면은 단점으로 볼 수있다.
