JWT) 프론트 입장에서 Refresh Token은 대체 어떻게 써야되는건데?

Q. JWT의 장단점?

JWT는 인증에 필요한 정보가 담긴 토큰을 클라이언트에서 저장하기 때문에 DB조회를 하지않아도 되고 서버 확장성에 좋다. 그러나 이러한 장점은 클라이언트에서 토큰이 탈취될 수 있다는 단점이 되기도 하다.

 

AccessToken 

• 인증시, 필요한 정보가 담긴 토큰으로 인증을 통과할 수 있는 key라고 보면 된다.
• 인증에 필요한 정보가 담기기 때문에 탈취에 대한 위험을 줄이기 위해 토큰의 유효기간이 매우 짧다. (30분 ~ 1시간)

RefreshToken 

• 유효 기간이 짧은 Access Token을 보조해주는 토큰으로 Access Token보다 유효기간이 길며, Access Token을 발급하는데 사용된다.
• 유효 기간은 2주 ~ 1달 정도 잡는거 같다.

 

 

JWT 특징 1. AccessToken이 탈취되어도 공격자가 Refresh Token이 없다면 30분 남짓만 털 수 있다.

Access Token이 유효기간이 짧은 이유이다. 짧은 시간마다 계속 바뀌어 탈취되더라도 제한적인 시간이 남기 때문에 해커가 나쁜 일을 할 시간이 별로 없어진다. 그러나 이렇게 Access Token이 짧아버리면 30분 마다 로그인을 다시 해야되는 귀찮은 서비스가 되어버린다는 단점이 생긴다.

 

JWT 특징 2. AccessToken가 만료되면 Refresh Token으로 갱신하여 로그인을 유지시킨다.

Refresh Token은 Access Token보다 지속 시간이 길다. Access Token이 만료되어도 Refresh Token으로 계속 Access Token을 갱신하면서 로그인을 길게 유지하는 것이다.

 

 

 

Q. 그렇다면 Access Token과 Refresh Token은 보통 어디다가 저장하는가?

보통 로컬 스토리지나 쿠키에 저장하는 형식을 따른다. 로컬 스토리지에 저장하는 것보다 쿠키에 저장하는 것이 더욱 안전하다고 평가되는 것 같다. (로컬 스토리지를 사용할 경우 XSS공격에 더 취약할 수 있다)

Refresh Token 프론트엔드 보관 위치

 

 

 

Q. Cookie는 서버에서 설정해서 심는 것이기 때문에 프론트에서 핸들링하기 힘들지 않나?

맞다. 프론트 측에서 필요할 때 쿠키를 추출하는 방식으로 활용할 수는 있긴 하다.

document.cookie에 접근하여 쿠키를 설정하거나 추출할 수 있다.

// 쿠키 가져오기 함수 예시
function getCookie(name) {
    // 쿠키 이름을 찾기 위해 Document.cookie를 가져옵니다.
    let cookies = document.cookie.split(';');

    // 모든 쿠키를 반복하면서 원하는 쿠키를 찾습니다.
    for(let cookie of cookies) {
        // 각 쿠키는 "key=value" 형식입니다. 공백을 제거하여 분리합니다.
        let parts = cookie.split('=');
        let cookieName = parts[0].trim();
        let cookieValue = parts[1];

        // 쿠키 이름이 찾고자 하는 이름과 일치하는지 확인합니다.
        if(cookieName === name) {
            // 일치하는 쿠키 값을 반환합니다.
            return cookieValue;
        }
    }

    // 찾는 쿠키가 없으면 null을 반환합니다.
    return null;
}

// 예를 들어, "username"이라는 쿠키 값을 가져오려면:
let username = getCookie('username');
console.log(username);

 

 

그런데 백엔드 서버에서 토큰을 쿠키 설정할때 Http Only 설정을 넣어서 아예 자바스크립트로 조작하기 힘들게 해놓기도 한다.

이럴때는 프론트엔드에서 어떻게 토큰을 조작해서 요청마다 쿠키를 넣는걸까?

 

Q. http only로 설정할 경우 프론트에서 refresh token이 거의 만료될 시점을 판단해서 갱신 요청을 보내는건 불가능하지 않나?

맞다. 그래서 HTTP Only 쿠키는 해당 도메인의 모든 요청에 포함된다!

그래서 refresh Token의 갱신 시점은 백엔드에서 결정하게 된다.

물론 거의 만료가 가까워져도 갱신 안 해줄수도 있다. 백엔드 재량이다.

그냥 보안 상 프론트에서 조작을 거의 못하게 해버린 것이다..

 

그러면 http only로 설계된 refresh token을 받았을때 프론트가 할 일은?

메인 페이지에 접속 시 refresh token이 있는지 확인하기 위해 확인하기 위해 token이 필요한 api를 한 번 쏴본다.  (주로 사용자 정보)

그리고 있다면 user 정보를 또 응답받는거고, 없다면 로그인 페이지로 리다이렉팅을 하거나 하면 된다.

 

 

 

요약

Refresh Token과 Access Token의 사용 전략은 서비스마다 각각 다르다.

Refresh Token의 제어권을 프론트에도 직접 주는 서비스도 있다. 이 경우는 로컬 스토리지에 넣어두고 알아서 잘 써먹으라는 이야기다.

인증 부분을 맡게 되었다면 백엔드 개발자와 잘 이야기해서 원만한 전략을 세워야한다.