JWT?

JWT?

JWT(JSON Web Token)의 약자로 Token이라는 암호화된 데이터를 JSON 형식으로 보낸는 방식으로 볼 수 있다. 로그인 시에 사용 되곤하는데, 어떻게 사용되는지 왜 사용하는지에 대해서 정리하려고 한다.

JSON?

서버에서 클라이언테로 데이터를 보낼 때 사용하는 형식으로 보면된다고 한다. 과거에 XML이라는 형식에서 좀더 성능이 좋고, 범용성이 좋은 것으로 변경했다고 보면 될 것이다.

Cookie

클라이언트가 웹사이트에 접속 할때 사이트에 서 사용하게 되는 일련의 작은 기록 파일이라고 봐도 된다. 서버는 클라이언트에 응답 헤더에 있는 Cookie를 통해 전달한다고 한다.
쿠키를 브라우저의 작은 파일로 저장되고, 그 파일에는 접속자 장치를 인식하거나 일부 데이터를 저장해주는 역할을 한다고 한다. 요 cookie에 로그인 정보(로그인이 완료되었다는) 것을 클라이언테에게 cookie로 보내준다고 한다. 그 다음 매번 ID, PW 같은 인증하지 않고 요청을 할 수 있다고 한다.
하지만 cookie는 보안상의 이유나 제약사항등의 이유로 인증에는 사용하지 않는다고 한다.

Session

일반적으로 여러 사이트 pw를 다 다르게 지정하여 사용하는 사람은 드물것이다. 그렇기 때문에 pw는 굉장히 민감한 정보이고, 사이트 가입시 개인정보 또한 노출 했을 때의 파장은 정말 심할 것이다. 보안상의 문제를 해결하기 위해 나온 것이 Session 방식이라고 한다.
cookie라는 정보 저장자체느 무언가 새로운 성능의 기술은 아니지만 민감한 정보를 다루고 보완점을 찾기 위해 나온 방식이 Session이라고 한다.
Session이라는 저장소에 ID, pw라는 인증 정보를 저장하고, 클라이언트가 로그인 정보를 cookie에 담아 세션 저장소에 있는 정보와 일치하는 것을 확인하는 것을 Session 방식이라고 한다.
이런 것을 stateful한 구조라고 한다. 직접 서버에 Session 이라는 저장소에 정보를 담아 확인하는 작업이라 그런 것 같다.
여기에는 몇가지 단점이 존재 해왔다고 한다.

• 세션 저장소의 문제가 발생하면 인증 체계가 무너져 이전 다른 인증된 유저 또한 인증이 불가

• 세션 저장소라는 물리적인 저장소가 필요

• 여전이 보안상의 문제가 있을 수 있음 세션 ID 탈취당했다라든가...

• 사용자가 많아질 수록 메모리가 많이 필요하다.

• 매번 요청시 세션 저장소를 조회 해야 한다.

  JWT

  위 방식에서 발생하는 문제점들을 보완하기 위해 나온 방식이 JWT 방식이라고 한다. Token 이라는 암호화된 데이터를 통해 주고 받는 것이라고 한다. JWT 방식의 특징 중 하나는 공개/개인 키를 쌍으로 사용하여 서명할 경우 개인 키를 보유한 서버가 토큰이 정상적인지 판단 할 수 있다고 한다. (여기서는 살짝 이해가 안간)

  JWT 구조(Header, payload, Signature)

  Header, palyload, Signature JWT 각각 "."으로 구분되어 있다.

1. Header : type 과 alg;Alorithm 으로 개인키에 대한 정보를 나타내고 있다고한다.

{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

payload 는 아래와 같은 정보를 담고 있다고 한다.

• iss(Issuer) : 토큰 발급자
• sub(Subject) : 토큰 제목 - 토큰에서 사용자에 대한 식별 값
• aud(Audience) : 토큰 대상자
• exp(expiration Time) : 토큰 만료 시간
• iat(Issued At) : 토큰 발급 시간
  이외에더 몇 가지 더 있지만 중요한 것만소개 하려고 한다. 그리고 이것은 표준 스펙일 뿐이고, 상황에 따라 추가해도 된다고 한다. 위 code 예시는 JWT 공식 홈페이지에서 가져온것이라 참고 사항일 뿐이다.
  참고로 payload나 header는 Base64Url 로 인코드 되었다고 한다. 그렇기 때문에 민감한 정보를 담으면 안된다. 누구나 쉽게 디코딩 할 수 있기 때문이다. JWT 공식 홈페이지에는 Debbuger로 Header와 Payload를 쉽게 디코딩 하여 볼 수 있다.

3. signature

{
  HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)
}

signature 에 담긴 정보는 your-256-bit-secret라는 서버가 가지고 있는 개인키로 암호화 한다고 한다. 그렇기 때문에 개인 쉽게 복호화 할 수 없는 구조라고 한다.

JWT 장점을은 다음과 같다고 한다.

• 토큰 자체가 인증된 정보이기 때문에 세션 저장소와 같은 별도의 저장소가 필요하지 않다.
• 암호화를 통해 보안성이 늘어났다(이부분은 사실 이해가 안간다...)

앞선 stateful 방식에서 stateless 방식으로 진화 된 것으로 이해된다.

JWT 단점 그리고 Access Token과 Refresh Token

역시 JWT 한계가 있다고 한다.

• base64 인코딩을 통해 정보를 전달하기 때문에 정보량이 많다.

• 토큰이 탈취 당하면 대처가 불가능 하다.

  특히 2번 째 이유가 굉장히 큰 문제라고 한다. Session일 경우 세션ID가 탈취당하면 문제가 되는 세션을 삭제하면 그만이다. 하지만 JWT는 statelsee한 방식이기 때문에 탈취당한 토큰을 서버에서는 검증할 방법이 없다고 한다.

  access token, refresh token

  그렇게 나온것이 exp 만료시간을 짧게 가져 간 것이라고 한다. 그렇게 함으로써 최소한의 보안성을 가져가는 것이라고 생각한다. 이를 access token이라고 한다. 만료 주기를 짧게 예를 들면 30분 혹은 1시간을 가져져가는 것이다. 만료가 되면 다시 인증하여 앞에 사용하였던 토큰을 무의미한게 만든것이라고 한다.
  그런데 이렇게 시간이 짧으면 사용자는 계속 로그인하는 과정을 겪어야 하기 때문에 굉장히 귀찮은 과정일 것이다.
  그렇게 나온 방식중 하나다 access token에 Refresh Token 이라는 token을 총 두개를 발급하는 것이라고 한다. Refresh token은 대신에 access token과 달리 만료시간을 비교적 길게 가져가는 것이라고 한다. 그리고 클라이언트가 만료된 access token일 경우 refresh token을 서버와 대조하여 다시 만료 기간이 짧은 access token 을 발급해주는 형식이라고 한다.

  마치면서

  JWT와 그리고 JWT가 왜 나왔는지 그리고 어떻게 사용되는지에 대해서 알아보았다.

참조

[WT(Json Web Token) 알아가기, 브런치, 2022년04월30일 접속]
https://brunch.co.kr/@jinyoungchoi95/1
[JSON 웹 토큰, 위키백과, 2022년04월30일 접속]
https://ko.wikipedia.org/wiki/JSON_%EC%9B%B9_%ED%86%A0%ED%81%B0
[JSON, 나무위키, 2022년04월30일 접속]
https://namu.wiki/w/JSON