jwt를 알아보기에 앞서, 기존 인증체계는 Cookie, Session으로 이루어졌었다.
기존 인증체계 중 하나인 '쿠키'는 노출될 떄, 민감정보(로그인정보)같은 것들이 전부 노출되므로 보안에 좋지 않다는 이유와, 조작 가능 성 등 다양한 단점들로 인해 인증에 온전히 사용하지 않는다.
세션또한 쿠키에 비해 좋다고 하더라도 사용자가 많아지면 서버 메모리에 과부하가 생길 수 있고, 서버에 문제가 생기면 사용자 정보가 모두 날라간다. 또한 , 서버거 커지면 서버 과부하를 막기위해 분산을 시키는데 유저가 로그인할 떄, 서버거 관리하는 세션스토어에 존재하지 않을 수 있다.
즉, A서버가 회원 정보세션이 존재하는데 B,C 서버에 배정되면 문제가 생길 수 있다. 마지막으로 세션ID가 탈취 됐을 떄,클라이언트로 위장하는 보안의 약점이 존재한다.
세션을 사용하면서 요청을 진행할 때마다 세션 저장소에 조회하는 작업을 DB접근을 통해 수행되는데,이런 점을 보완하기 위해 등장한 것이 'JWT' 이다.
JWT는 인증에 필요한 정보들을 토큰에 담고, 암호화 시켜서 사용
기본적인 인증 진행 구조는 쿠키와 크게 다르진 않지만, JWT는
서명된 토큰이라는 점이 다르다.
공개/개인 키를 쌍으로 사용해서 토큰에 서명할 경우
서명된 토큰은 개인 키를 보유한 서버가 이 서명된 토큰이 정상적인
토큰인지 인증할 수 있다.
JWT의 구성 요소는 Header, Payload, Signature 로 구성됐고,
구성 요소는 '점(.)' 으로 구성 ,이러한 구조로 형성되어있음 -> aaaaa.bbbbb.cccc
Header 에는 토큰의 타입, 서명 생성에 이용된 알고리즘을 저장
Payload 에는 Claim이라는 사용자와 토큰에 대한 속성을 Key-Value 형태로 저장
Signature 는 JWT에서 가장 중요한 서명
디코딩된 header, payload를 합치고 이를 서버가 가지고 있는 개인키를 통해서 암호화되어 있다
즉 Signature은 서버에 있는 개인키로 암호화를 풀 수 있으니,
다른 클라이언트가 임의로 이것을 복호화할 수 없다!!
JWT의 장점이라고 하면,
이미 토큰 자체가 인증된 정보라서, 세션 저장소와 같은 별도의 인증 저장소가 꼭 필요로 하지 않는다.
그리고 세션과 다르게 클라이언트의 상태를 서버가 저장하지 않아도 되고, 보안성이 늘어나고, 다른 서비스에 이용할 수 있는 공통적인 스펙으로써 사용