JWT(JSON Web Token)

JWT의 존재 이유

가상의 시나리오

 

어떤 웹 어플리케이션을 하나 개발한다고 생각 해보자 당연히 클라이언트가 있고, 그 클라이언트와 통신을 할 API 서버를 두게 된다. 그럼 거기에는 자연스럽게 데이터베이스가 따라간다. 이런 구조로 서비구를 구동 중에 있다가 서비스가 잘되어서 이용자가 많이 늘어 나게 되었다.

 

그런 경우에 클라이언트는 보통 문제가 되지 않는다. 오프라인 앱이라면 그냥 유저가 가지고 있는거니까 상관이 없고, 웹 어플리케이션이라면 CDN을 통해서 저렴하게 배포를 할 수가 있다. API서버는 어떨까 이 경우에도 스케일 아웃을 해서 서버를 늘리면 된다. 서버를 굴리기 위한 비용도 그닥 비싸지 않다.

 

이런 경우 가장 번거로운건 바로 데이터베이스 이다. 병렬처리 하기가 쉽지 않기 때문에 기본적으로 분산시키는게 쉽지 않다. 요즘에는 스케일 아웃이 간편한 데이터 베이스도 많지만 문제는 비용이다. 편한 기능 만큼 그에 합당한 대가를 받아 가기 때문이다.

 

그리고 여러명의 사용자의 데이터를 대신 보관해 줘야 한다는 자체로, 일단 관리할 일이 늘어나고, 번거롭게 되는걸 피하기 힘들다.

 

그런데, 만약 전통적인 클라이언트-서버-데이터베이스 구조에서 하나를 지워 버릴 수 있다면 어떨까? 하나를 지워 버리면서도 기존에 할 수 있던 역할을 그대로 수행할 수 있다면 어떨까? 가장 번거롭고

관리하기 귀찮았던 데이터베이스를 지워 버리는 것이다.

 

JWT 이용

JWT(JSON Web Token)을 이용 하면, 이렇게 유저 데이터를 유저가 직접 관리하게 끔 할 수 있다. 근데 유저데이터를 유저가 관리하게 하는데 굳이 JWT가 왜 필요할 까? 조금 다른 점이 존재하는데, 그냥 유저 데이터를 클라이언트에게 맡겼다면, 클라이언트에서 직접 데이터를 수정할 수 있는게 보통 당연할 것이다. 

 

그런데 JWT를 이용하면 이런게 가능하다. 유저가 자신의 데이터를 볼 수는 있는데 수정은 하지 못하게 하는 것이다. 그리고 그 데이터를 수정을 하려고 하면, 무조건 서버를 통해서만 가능하게 하는 것이다.

 

서비스를 관리하는 입장에서는 편리함이 증대된다. 데이터 관리를 직접할 필요가 없고 유저 보고 알아서 하라고 하면 되는데 유저가 마음대로 조작은 할 수 없고 서버에서만 수정을 할 수 있기 때문이다. 이걸 가능하게 하는게 JSON Web Token이다.

JSON Web Token을 보면, 실제로 좀 더 길긴 하겠지만, 대강 이런 모양새로 생겼다. 곤충처럼 3마디로 이루어져 있다. 

• Header : 어떤 타입의 데이터를 다룰지, 어떤 암호화,해싱 알고리즘을 사용할지에 대한 정보를 담는다.
• Payload : 여기에는 이렇게 가운데 JSON형식 데이터처럼, 실제 보관할 데이터를 담는다.
• Signature : JWT에서 가장 중요하다. 이것 덕분에 유저는 데이터를 보기만 할 수 있고, 서버에서만 수정을 할 수 있게 하는걸 가능하게 한다. 

 

+ 저 문자를 보면 이 Header랑 Payload가 꼭 암호화가 된 것처럼 보이지만 실제로는 그냥 데이터 주고 받기 편하게 base64 포맷으로 변환만 한 것이다.  중간에 보이는 JSON 데이터처럼, 언제든 유저가 다시 변환해서 확인할 수 있는 데이터라고 할 수 있다.

 

+Signature은 클라이언트에서는 건드릴 일이 없고 그대로 주고 받기만 하는 데이터이다. 전적으로 Signature의 관리는 서버에서 한다.

 

가상시나리오

클라이언트에서 서버로 무언가 데이터를 수정을 하기 위해 요청을 보낸다고 생각해보자 이 JSON Wev Token을 통째로 보내게 되는데, 이때 한번 유저가 임의로 값을 수정했다고 생각해 보자

 

=> money 값을 원래의 15,00에서 0을 하나 더 붙여서 150,00으로 바꾸어 보내는 것이다.

 

그 데이터를 서버에서 받는다. 그 다음에 바로 할 일은 이 JSON Web Token값이 임의로 조작이 되었는지를 확인하는 것이다. 조작 여부를 확인하는 용도로 사용하는게 바로 이 Signature이다. Header와 Payload를 조합하고 비밀키를 이용해서 해시 값을 만들어 내는데, 이게 바로 Signaturere가 된다.

 

즉 서버가 바로 하는 일은 유저가 보내준 Header와Payload를 이용해서 직접 Signature를 만들어보는 것이다. 그리고 나서 유저가 기존에 보내주었던 Signature 값과 비교를 하는 것이다. 값이 다르면 이건 무언가 조작된 데이터라는 걸 의미하게 된다.

 

이렇기 때문에 비밀키는 이름에  걸맞게 서버에서만 알고 있어야 하고, 클라이언트는 절대 알면 안되는 값이다. 서비스 관리자 페이지 계정 정보 같은 거라고 생각하면 비슷하다고 볼 수 있다.

 

 

정리

JSON Web Token 덕분에 데이터 보관은 유저가 하고, 유저가 자신의 데이터를 보는건 언제든지 가능한데 그걸 수정하는 건 유저가 할 수 없고, 서버로 보내야 하는 구성이 가능해졌다. 이런 의미에서 사실 이 방식이 꼭 JSON형식을 사용해야 하는 건 아니다. XML이라던지 다른 어떤 걸 사용해도 상관 없다.

 

하지만 프로그래밍 언어를 통해서 유연하게 다루기 편하고, 데이터 스키마 수정이 자유로운 JSON의 장점이 크기 때문에 JSON이 대표격으로 쓰이게 되었다.

 

 

[출처-https://youtu.be/7abbNwuCXbg]