JWT

• JSON WEB TOKEN
• 통신 양자간의 정보를 JSON 형식을 사용하여 안전하게 전송하기 위한 방법
• 정보가 토큰 자체에 포함된 클레임 기반 토큰

JWT 는 왜 생겼을까?

• 클라이언트와 서버 모두 HTTP를 이용해서 통신하는데 그 HTTP 가 stateless 프로토콜의 일종이기 때문이다.
• HTTP에서 각 요청을 독립적인 트랜잭션으로 취급하여 모든 상태가 어디에도 저장되지 않는 특성을 가진다. 즉 이전 요청과 그 이후의 요청은 서로 관련이 없음을 뜻한다.
• 따라서 HTTP 그 자체만으로는 사용자가 정확한 정보로 로그인을 과정을 거쳐 인증에 성공하더라도, 그 인증 상태가 저장되지 않는다. 로그인하고나서 다른 페이지로 이동하면 다시 로그인해야 하는 것이다. 그래서 이런 불편함으로 인해 서버기반 인증과 토큰기반 인증이 등장했다.

서버 기반 인증

• 서버기반 인증에서는 사용자가 성공적으로 로그인한 이후 서버에서 사용자에 대한 세션을 생성한다.
• 또한 이와 동시에 사용자의 브라우저에는 세션 ID 를 저장하는 쿠키가 생성된다.
• 서버는 이 세션 ID 를 통해 사용자를 식별하고, 사용자에 대한 정보를 저장, 관리한다.
• 중요한 건 서버에서 사용자에 대한 세션 정보(유저의 ID, 이름, 권한 등)를 가지고 있다는 것이고 이는 서버에 큰 부담이 될 수 있다.

토큰 기반 인증

• 유저의 정보를 서버에 저장하지 않는다.
• 서버는 토큰을 발급하고 발급한 토큰을 검증할 뿐이다.
• 서버 기반 인증과 달리, 유저 상태의 저장 책임은 서버에서 클라이언트로 이동하게 된 것이다.
• 클라이언트는 서버가 발급한 토큰을 web storage 인 session storage 혹은 local storage 에 저장한다.
• 위에 저장한 토큰을 이용해 클라이언트는 서버에 요청을 할 때 HTTP header에 토큰을 실어 전송한다.
• 단점도 있다.
  - JWT와 같이 토큰 자체에 정보가 저장되는 형태의 토큰은 클라이언트에 유저의 정보가 저장되므로 노출되기 쉽다.
  - 세션에 비해 사이즈도 크다.

JWT 를 언제 쓸까?

Authorization (인가, 권한부여)

• 로그인 이후의 요청은 JWT를 포함해서 사용자가 특정 경로, 서비스, 리소스에 접근하는 것을 허락해준다.
  - 마이페이지, 글쓰기 등
  

Information Exchange (정보 교환)

• public/private key 쌍을 이용해서 JWT가 서명될 수 있기 때문에, 안전하게 정보를 주고받는데도 잘 쓰인다.
• 보낸 사람에 대한 인증도 되며, 서명은 헤더와 페이로드를 사용해 계산하므로 내용이 변조되지 않았다는 사실도 알 수 있다.

회고

• 서버 기반의 인증의 문제점으로 인해 토큰 기반 인증이 만들어졌지만 여전히 단점은 있다. 존재하는 수많은 기술을 필요한 때에 공부하고 필요한 곳에 적절하게 사용하는 것이 필요하다고 느꼈다.

참고

https://jwt.io/