이번 글은 JWT에 대해 정리하며 일반적인 oauth와 jwt에 대해 설명해보려 한다.
OAuth 시리즈 1번째 글에서 블라블라 떠든 서론 중에 jwt가 어떤 용도며 장점을 가졌는지 모르는체 그냥 기능적으로만 사용할 줄 알았다고 얘기했었다.그 와중에 OAuth와 jwt의 차이점에 대해 알아보고 명확한 장점과 단점, 구조, 어떤 정보를 담고 있는지 등의 관점으로 더 깊게 공부를 해보라는 기업협업 팀장님의 말씀이 있었고 그 과정에서 OAuth와 JWT에 대해 깊게?라고는 부끄러워 말 못하겠지만 어느정도 이해할 수 있었던 것 같다.
JWT 란?
JSON WEB TOKEN의 약자로(jenjang whatthe f) 전자 서명 된 URL-safe (URL로 이용할 수있는 문자 만 구성된)의 JSON이다.
여기서 말하는 전자 서명은 JSON의 변조를 체크할 수 있으니 즉 JWT의 정보가 변조되었는지 체크가 가능하다는 의미일 것이다.
로그인 시 서버에서 클라이언트로 해당 토큰을 반환하며, 클라이언트에서 서버에 요청을 보낼 때 Http request 헤더에 토큰을 넣어 요청하면 서버는 이 헤더에 있는 토큰안의 정보를 통해 인가를 진행한다.
JWT의 구성
위 사진은 JWT의 구성을 나타낸 사진으로 dot(.)을 기준으로 3분류 되어있는 것을 알 수 있다.
헤더(header)
헤더에는 토큰의 유형(jwt)과 어떤 해시 알고리즘이 사용되었는지에 대한 내용이 담긴다.
내용(payload)
페이로드에는 key값과 value로 이루어진 클레임이 담겨있는데
보통 사전에 미리 등록된 정보로는 만료시간, 식별자, 발급시간 등의 등록된 클레임이 있는 반면
서버에서 토큰을 만들 때 유저를 특정할 수 있는 정보도 이곳에 담는다.
즉 페이로드에 담겨있는 유저정보를 추출하여 서비스 내의 특정 리소스에 접근해도 되는지 또는 해당 유저가 어떤 유저인지를 인증&인가에 사용할 수 있다.
🚨 jwt는 해석이 불가능하지도 않으며 엄청 복잡하지도 않다고 한다. token이 유출될 시 payload 안에 유저의 민감한 개인정보가 담겨있을 경우 큰 피해가 있을 수 있으니 이곳에 민감한 정보는 최대한 담아서는 안된다
서명(signature)
헤더와 내용을 base64로 인코딩 한 것이다.
이를 헤더에서 지정한 해싱 알고리즘을 이용하여 해싱을 하면 서명이 생성된다.
헤더와 내용을 바탕으로 인코딩 한 것이라 누군가 임의로 jwt 안의 정보를 임의로 조작한다면 signature가 달라 올바르지 않은 정보임을 알아챌 수 있다.
JWT 사용 예
JWT에 대해 간략히 알아봤는데 어떨 때 주로 사용하는지와 왜 그런지에 대해 좀 더 알아보려 한다.
정보 교류 용
두 집단간에 정보를 교류할 때 사용할 수 있다고 한다. 두 집단의 정보 교류에 가장 중요한 점은 바로 안정성인데 정보가 조작되었을 경우 서명 부분에서 조작됨을 캐치할 수 있으니 안정성 있게 정보를 교류할 수 있다고 판단하여 사용하는 것 같다.
회원 인증
토큰 payload에 담긴 정보를 통해 회원을 인증 또는 인가하는 방식에 많이 사용된다.
