JWT의 정의와 사용하는 이유

JWT란

JWT 정의

💡 JWT는 Json Web Token의 약자로 웹 표준 RFC 7519로 정의된, JSON 객체를 사용해 가볍게 정보를 안전하게 전송할 수 있는 토큰 형식이다. 해당 토큰은 쉽게 읽을 수 있고 자체 가능한 정보를 포함하고 있으며 필요한 경우 정보의 수정을 방지하기 위해 서명도 가능하다.

JWT 구조

JWT는 3가지 구조로 되어있다.

1. Header(헤더)
2. Payload(페이로드)
3. Signature(서명)

Header

💡 헤더는 토큰의 타입과 사용된 알고리즘을 정의하는 JSON 객체이다.

          토큰의 타입 : 일반적으로 JWT 알고리즘 : HMAC SHA256, RSA 등

 

예시

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

위 정보를 해석→ HS256 알고리즘으로 되어있는 JTW 토큰 형식이다.

Payload

💡 페이로드는 클레임 정보를 가지고 있다. 이때 클레임이란, 사용자의 대한 정보나 데이터를 의미한다. 클레임은 사용자의 아이디, 만료 시간 등 정보를 포함한다. 이러한 클레임은 등록된 클레임, 공개 클레임, 비공개 클레임이 있다.

 

등록된 클레임 : 서비스에서 필요한 정보를 제공하기 위해 예약된 클레임 이름

공개 클레임 : 공개적으로 정의된 클레임, URL 형식을 사용해 정의

비공개 클레임 : 송신자와 수신자 사이에 합의하에 사용되는 클레임

 

예시

{
  "sub": "1234567890",
  "name": "evan",
  "admin": true,
  "iat": 1516239022
}

Signature

💡 서명은 헤더의 인코딩 된 값과 페이로드의 인코딩 된 값을 합친 후 헤더에서 정의된 알고리즘을 사용해 서명된다. 이러한 서명은 토큰이 중간에 변경되지 않았음을 검증하는 데 사용한다.

예시

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

aaaaaa.bbbbbb.cccccc

헤더 부분 : aaaaaa

페이로드 부분 : bbbbbb

서명 부분 : cccccc

JWT 사용예시

보통 JWT는 Authorization 헤더를 통해 Bearer 토큰으로 전송 → 인증하는 데 사용 서버는 서명을 검증하고 페이로드에서 필요한 정보를 추출하여 요청의 유효성을 확인

JWT로 인증/인가하는 방법

ex) 로그인 과정

1. 클라이언트가 로그인을 한다.
2. 서버에서는 로그인 인증 정보를 검증한다.
3. 인증 정보 검증에 문제가 없을 경우 Access Token(JWT)를 생성한다.
4. 로그인이 되었다는 응답과 함께 토큰을 전달한다.
5. 이후 클라이언트는 매 요청 시 헤더에 토큰을 담아서 요청한다.
6. 서버는 요청을 받아을 때 토큰을 검증해서 접근 가능한지 검증한다.
7. 검증 완료 후 클라이언트가 요구하는 데이터를 응답한다.

JWT 인증인가의 장단점

장점

💡 1. JWT를 통해 인증정보를 가지고 있어서 서버는 무상태로 유지시켜도 다른 기능에 지장이 없다. (무상태로 인해 서버의 확장성 증가)

     2. JWT의 서명으로 토큰 내부의 조작 여부를 확인할 수 있으므로 보안성이 증가한다.

     3. 서버 입장에서는 토큰 검증만 하면 되므로, 데이터베이스 조회할 이유가 없어진다 → 조회하는 시간이 없어진다

 

단점

💡 1. 토큰 크기로 인한 요청 헤더 크기가 증가하고 이는 네트워크 오버헤드 발생할 가능성을 가진다.

     2. JWT 유효 시간 설정에 따른 보안성 약화의 가능성을 가진다 → 한번 발급한 토큰으로 검증 처리가 이루어지기 때문

 

쿠키/세션이 아닌 JWT를 사용해야 하는 이유

💡 JWT를 사용해야 하는 이유

1. 서버를 배포할 때 서버의 발생하는 부하를 줄여주기 위해 로드 밸런싱을 하게 되는데 쿠키/세션 방식에서는 세션의 일관성을 유지하기 위해 추가적으로 작업을 진행해야 한다. → (사용자의 인증 상태를 서버에서 관리하기 때문)
2. 쿠키/세션 방식의 경우 쿠키를 안전하게 관리하지 못할 경우 보안 취약점이 생길 수 있다.
3. 쿠키/세션 방식에서 세션 정보를 서버에서 관리하기 때문에 매 요청 시 세션을 조회하는 시간이 걸린다.
4. JWT 유효 시간 설정에 따른 보안성 약화 단점→ Refresh Token으로 어느 정도 해결이 가능하다.