JWT란?

JWT는 "Json Web Token"의 약자로써 RFC7519로 인터넷표준 암호화 토큰이다. 해당 기술은 세션기반의 인증보다는 Stateless기반(비세션기반)의 웹페이지에서 주로 사용을 한다고 한다.

 

 세션기반의 인증은 클라이언트가 로그인시 해당 유저의 정보를 서버의 세션에 저장을 한뒤 서버의 세션값을 유저에게 보낸다. 그리고 정해진 시간안에서는 세션이 계속 유지가되면서 서버와의 데이터전송이 가능하다. 

 

다만 해당 세션기반의 가장 치명적인 약점은 바로 "확장성"이다.

 

예를들어 A라는 웹애플리케이션을 처음 설계를 할때는 사용자가 많지않을꺼라 생각해서 100명정도의 수용량을 계산하여 설계했다.  그런데 예상치 못한 인기에 B라는 웹애플리케이션을 또 하나 배치하여 분산(이런 기술을 로드밸런서라고 한다)을 시키기로 하였다.

로드밸런서란 여러명의 이용자가 하나의 서버에 접속을 하여 서비스에 지장을 주는 것을 방지하기 위한 기술로 일정한 수용량이 되면 로드밸런서가 일부 사용자를 다른 서버로 이동시켜서 서버에 부하를 방지하는 기술이다.

 

 여기까지는 크게 문제가 없다. 로드밸런서로 서버의 부하도 막고 아무런 문제가 없어보인다. 진짜 문제는 여기서부터인데 A와 B는 같은 웹애플리케이션을 실행시키지만 결론적으로만 생각해보면 A와 B는 다른 서버이기 때문에 둘은 세션 ID값이 다를 수 밖에 없다. 그래서 A라는 곳에서 놀다가 B라는 곳으로 이동을 하게되면 다른 ID값이기 때문에 다시 인증을 해야하는 경우가 온다.

물론 세션 ID값을 공유하거나 다루는 서버를 만들고 A와 B를 연결하는 방법등도 존재한다고 한다.. 여기서는 다루지 않는다.

---

그래서 사람들은 인증방식의 정보를 세션이 아닌 사용자에게 주면 해결이 되는게 아닌가?에서 나온 방법이 바로 JWT이다.

구조는 Header, Payload, Signature 이렇게 3개로 구성이 되어있다.

우선 HEADER 부분을 보면 "alg": "HS256"이 부분이 눈에 띈다. 여기서 HS256은 JWT의 암호화방식은 HMAC(HS256 등), RSA, ESDSA가 있다. 그리고 "typ": "JWT"로 JWT임을 증명한다.

 

그 다음은 PAYLOAD는 사용자와 서버 간 주고 받기로 한 데이터들로 구성이 되어있다. PAYLOAD에 있는 속성들은 클레임 셋(Claim Set)이라고 부른다.

 

마지막으로 SIGNATURE는 위의 HEADER와 PAYLOAD의 값들을 "alg"에 정의된 방식으로 암호화하고 Base64로 인코딩을 한다. 그리고 위의 사진에 Encoded부분을 보면 .(점)으로 HEADER, PAYLOAD, SIGNATURE를 합치면 마침내 JWT가 완성이 되는것이다.

 

JWT 공식 페이지 : JSON Web Tokens - jwt.io

JWT.IO