JWT (JSON Web Token)

 

포스팅을 읽기 전 읽어보면 좋을 포스팅

2023.02.02 - [코딩/알쓸코잡] - Cookie / Local storage & Session storage

 

JWT (JSON Web Token)

JWT 는 유저를 인증 / 식별하기 위한 토큰 기반의 인증이라고 볼 수 있다.

JWT 는 토큰 자체에 [사용자의 권한 정보 / 서비스를 사용하기 위한 정보] 가 포함되어 있는데,

이 JWT 는 서버가 아닌 '클라이언트'에게 저장되기 때문에 서버의 부담을 덜 수 있다는 장점을 가진다.

 

JWT 을 쓰는 이유

JWT을 사용하는 이유는 두 이유가 있다. (서버 기반 인증의 문제점 & JWT의 장점)

 

서버 기반 인증 방식의 문제점

• 세션 : 세션이란, 유저가 인증을 할 때 해당 인증에 대한 정보들을 서버가 가지고 있는 것을 말한다. 세션의 경우 해당 데이터를 메모리에 저장하게 되는데, 당연하게도 유저의 수가 많아질수록 DB 성능이 저하될 수밖에 없다.
• 확장성 : 확장성이란, 단순 서버 사양이 아닌, 여러 개의 프로세스 또는 여러 개의 서버 컴퓨터를 추가하는 것을 의미한다. 이는 트래픽 / 메모리와 관련된 얘기로, 앞서 얘기한 세션을 사용할 경우 확장성이 낮아지게 된다.

정리하자면, 서버에 클라이언트의 정보를 저장하는 것은 서버에 부담을 줄 수 있기 때문에 좋은 방법이 아니다라는 것.

JWT의 장점

• 클라이언트로부터 받은 데이터를 서버측에서 저장하지 않는 것을 무상태(stateless)라고 한다. 또 이는 '서버 기반 인증 방식'이었다면 '저장'을 위해 사용되어야 했을 트래픽을 다른 것들을 활용할 수 있는 가능성을 갖기 때문에 이는 높은 확장성을 가진다고도 말할 수 있다. (무상태/확장성)
• 클라이언트가 서버에 요청을 보낼 때, 더 이상 쿠키를 전달하지 않기 때문에 '쿠키'로 나타날 수 있는 취약 요소가 사라진다.(보안성)

 

JWT의 단점

• 정보가 많아질수록 토큰 길이가 길어져 네트워크 부하가 증가할 수 있으며,
• 밑에서 설명할 Payload 를 탈취당할 우려도 있으므로 보안성이 낮다.
• 토큰 자체를 아예 탈취당해버린다면 대처하기 어려워 완벽한 인증 방식은 아니다.

 

JWT 순서

순서는 위와 같다.

1. 클라이언트에서 아이디, 비밀번호로 웹 서비스를 인증함

2. 서명된 JWT 생성 후 클라이언트에게 응답함

3. 클라이언트가 서버에 데이터 추가요구를 할 때, JWT 를 HTTP Header에 첨부함* (밑에서 설명)

4. 서버에서 클라이언트로부터 온 JWT 검증함

 

JWT 구조 

JWT의 구조는 Header / Payload, Signature 세 가지로 이루어져있다.

• Header : JWT에서 사용할 타입(JWT)과 알고리즘 종류를 담겨 있다.
• Payload : 서버에서 첨부한 사용자 권한 정보와 데이터가 담겨 있다. 
• Signature : Header의 인코딩 값과 Payload 의 인코딩 값을 합친 후 비밀키로 만든 뒤 생성한 값이 담겨 있다.