JWT

Json 객체에 인증에 필요한 정보들을 담은 후 비밀키로 서명한 토큰으로, 인터넷 표중 인증 방식이다. 공식적으로 인증(Authentication) & 인가(Authorization) 방식으로 사용된다.

구조

• Header

  • JWT에서 사용할 토큰의 타입과 암호화 알고리즘 정보로 구성

    • alg: Signature에서 사용하는 알고리즘
      Signature에서 사용하는 알고리즘은 대표적으로 RS256(공개키/개인키)와 HS256(비밀키(대칭키))가 있다.
    • typ: 토큰 타입

  • key-value 형태로 구성

• Payload

  • 사용자 정보의 한 조각인 클레임이 들어있다.

    • 토큰에는 여러 개의 클레임을 넣을 수 있음
    • Payload에는 민감한 정보를 넣으면 안됨 -> 암호화 X

  • 서버로 보낼 사용자 권한 정보와 데이터로 구성

• Signature

  • 헤더와 페이로드의 문자열을 합친 후, 헤더에서 선언한 알고리즘과 key를 이용해 암호화한 값.
  • Header와 Payload는 단순히 Base64url로 인코딩되어 있어 누구나 쉽게 복호화할 수 있지만, Signature는 key가 없으면 복호화할 수 없다. 이를 통해 보안상 안전하다는 특성을 가질 수 있게 되었다.

장단점

• 장점
  • 데이터 위변조를 방지한다.
  • 인증에 필요한 모든 정보를 담고 있기 때문에 인증을 위한 별도의 저장소가 없어도 된다.
  • 세션과 다르게 서버는 무상태가 된다.
  • 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.(쿠키와의 차이)
  • 모바일에서도 잘 동작한다.
• 단점
  • 쿠키 / 세션과 다르게 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
  • Payload 자체는 암호화가 되지 않아 중요한 정보는 담을 수 없다.
  • 토큰을 탈취당하면 대처하기 어렵고, 특정 토큰을 강제 만료하기 어렵다.

JWT 탈취 시 서명의 역할
탈취된 JWT는 서명도 함께 포함되어 있습니다. 공격자가 JWT를 그대로 사용하면, 서명이 유효하므로 서버는 이를 정상적인 JWT로 인식합니다. 이 경우 서명 검증은 여전히 성공하며, 공격자는 유효한 JWT를 사용하는 것처럼 행동할 수 있습니다. 그러나 공격자가 JWT의 내용을 변경하려고 하면 서명이 달라지기 때문에, 서버에서 서명 검증에 실패하게 됩니다.

리프레시 토큰

• AccessToken을 탈취 당했을 경우에 대한 최소한의 대비
• AccessToken의 유효기간을 짧게 설정하여 탈취 되어도 사용기간을 줄이는 효과
• RefreshToken을 통해 다시 AccessToken을 발급받아 사용
• RefreshToken은 인증 정보를 담고 있지 않고, 오로지 AccessToken 재발급 용도로만 사용