[Back-end] jwt token 통신과정

JWT Token 통신과정

Token Object 구조

[기다릴개] 프로젝트 내에서 JWT 토큰을통한 로그인 유지를 구현하기 위해 다음과 같은 전략하에 통신을 진행하였다.

{
    "status" : 200,
    "message" : "token 발급 성공",
    "data" : {
        accessToken : {
            "data" : eyJASKLDAHDuaksjdhaksd..,
            "expiredAt" : 1504819077
        },
        refreshToken : {
            "data" : eyJASKLDAHDuaksjdhaksd..,
            "expiredAt" : 1704819077
        }
    }
}

위와같은 형태이며, 각 토큰의 목적은 다음과 같다.

accessToken : 인증 수단으로써의 토큰. 인증을 위해 사용되며, 사용자 정보가 담겨져있다.

refreshToken : 인증 수단(accessToken)을 갱신하기 위한 토큰.

jwt토큰은 서버에서 상태를 유지하기 위한 기술이기때문에, 클라이언트 쪽에서 토큰을 유지하고, 통신에 이용하므로 아무리 암호화 되있는 토큰이라고 할지라도 토큰값 자체는 패킷스니핑등의 위험으로부터 안전하지 않으며, 짧은 주기의 갱신이 필요하다. 프로젝트 내에서는 accessToken의 만료시간을 15분으로 설정하였다.

하지만 보안상의 이유때문에 15분마다 새로운 로그인을 시도해야한다면 그것은 사용자의 불편함으로 이어질 것이다. 이러한 불편함을 해소하기 위해서는 갱신된 토큰값으로 로그인이 유지되어야 한다.

refreshToken은 바로 이를 위한 수단이다. 클라이언트는 통신 맨 첫단추에 refreshToken값을 이용해서 만료된 accessToken을 갱신하고, 갱신된 accessToken 값을 이용하여 통신을 진행한다. 이를 논리적으로 구분해서 정리하면, 다음과 같다.

서버에서 제공되는 2개의 API

1. (POST) api/auth/login : 로그인 뷰에서 요청 (token object를 새로 발급)

   • requestParam : id / pw

2. (POST) api/auth/refresh : accessToken 만료시 요청 (accessToken만 발급)

1. requestHeader : refreshToken

Client TO Server 통신 과정

1. Client 개인 저장소에 refreshToken 존재 true / false

1 - 1. true

• refreshToken 의 expiredAt이 현재시간(now)보다 less / more (만료기간이 끝났다 / 끝나지 않았다)

  • less : 로그인 뷰로 전환후 재 로그인 진행

  • more : accessToken의 expiredAt이 현재시간(now)보다 less / more (만료기간이 끝났다 / 끝나지 않았다)

    • less : api/auth/refresh 통신 진행하여 accessToken 갱신, 기존 시도한 통신 진행

    • more : 통신 진행

1 - 2. false

• 로그인 뷰로 전환후 재 로그인 진행

이러한 전략을통해 클라이언트 to 서버간의 요청횟수를 줄이고 로그인 상태를 유지할수 있었다. expiredAt에 이용되는 숫자 체계는 리눅스 시간을 기준으로 사용되었으며, 실제 프로젝트에서 사용할 때에는 token, expiredAt외에 별도로 now라는 서버의 현재시간을 담는 변수를통해 클라이언트와 서버간의 시간차이 (타임존 이슈등으로 인한)를 계산하여 사용할수 있도록 구성했다.