JWT (Json Web Token)

웹 표준 (RFC 7519)로 두 개체에서 Json 객체를 사용하여 가볍고 자가수용적인 방식으로 정보를 안정성 있게 전달

 

JWT 구성요소

.을 구분자고 3가지 문자열로 구성

aaaa.bbbbb.ccccc → 헤더, 내용, 서명으로 구성

1. Header 헤더
   • 헤더는 typ 와 alg 두 가지 정보를 지니고 있다.
     • typ은 토큰의 타입 → JWT로 지정
     • alg은 해싱 알고리즘을 지정 → HMAC, SHA256, RSA가 일반적으로 사용되고 토큰을 검증할 땐 signature부분에서 사용됨
   • ex. { “typ” : “JWT”, “alg” : “HS256” }
2. Payload 내용
   • 토큰을 담을 정보
   • 정보의 한 조각을 클레임(Claim)이라 부르며 name 과 value의 한쌍으로 존재
   • 토큰에는 여러 개의 클레임들을 넣어줄 수 있다.
   • 클레임의 종류
     • 등록된(Registered) 클레임
       • 등록된 클레임들은 서비스에서 필요한 정보들을 담기 위하여 이름이 이미 정해진 클레임
       • 등록된 클레임의 사용은 모두 선택적(Optional)이며 이에 포함된 클레임의 이름은
         • iss : 토큰 발급자 (issuer)
         • sub : 토큰 제목 (subject)
         • aud : 토큰 대상자 (audience)
         • exp : 토큰 만료시간 (expiration)
           • 시간은 NumericData 형식으로 되어있어야 하며 언제나 현재 시간보다 이후로 설정되어 있어야 한다.
         • nbf : Not before 토큰의 활성 날짜
           • NumericData형식으로 되어 날짜를 지정하며 이 날짜가 지나기 전까지 토큰이 처리되지 않는다.
         • iat : 토큰이 발급된 시간 (issued at), 토큰의 age 판단 가능
         • jti : JWT의 고유 식별자, 중복 처리를 방지하기 위하여 사용 → 일회용 토큰에 사용하면 유용
     • 공개 클레임
       • 충돌이 방지된 이름을 가지고 있어야 한다.
       • 클레임 이름을 충돌을 방지하기 위해선 URI 형식으로 짓는다.
       • ex. “https:// …” : true
     • 비공개 클레임
       • 등록된 클레임도, 공개된 클레임도 아닌 경우
       • 클라이언트-서버의 양측간에 합의하에 사용되는 클레임 이름
       • 이름이 중복되어 충돌될 수 있으니 사용에 주의
3. Signature 서명
   • 헤더의 인코딩 값과 정보의 인코딩값을 합친 후 주어진 비밀키로 해쉬를 하여 생성
   • 이렇게 만든 해쉬를 base64 형태로 나타낸다.

 

로그인 인증시 JWT 사용

만약 유효기간이 짧은 토큰은 발급하게 되면 사용자 입장에서 자주 로그인을 해야하므로 번거롭고

유효기간이 긴 토큰을 발급하게 되면 제 3자에게 토큰을 탈취당할 경우 보안에 취약하다는 단점이 존재

이런 단점을 보완하기 위해 Refresh Token을 사용하게 되었고 Access Token과 똑같은 JWT으로

Access Token의 유효기간이 만료되었을 때 Refresh Token이 새로 발급해주는 열쇠가 된다.

 

Access Token의 유효기간은 짧게, Refresh Token의 유효기간은 그보다 길게 설정하여 Access Token가 만료되면 Refresh Token을 이용하여 새롭게 발급해준다.

이 방법또한 Access Token이 탈취당한다고 해도 정보가 유출되는 걸 막을 수 없지만 짧은 유효기간 때문에 탈취되는 가능성을 줄인다는데 의의를 둔다. Refresh Token 또한 유효기간이 만료됐다면 사용자는 새로 로그인해야하고 탈취 될 가능성이 있기에 적절한 유효 기간 설정이 필요하다.