개요
현재 ERP를 기획 및 개발 하고 있다. 추후, ERP에 시스템 내부 성능이나, 어떤 사람이 장비를 빌렸으며, 어떤 서버가 동작하는지 확인 하기 위해서 대쉬보드를 만들어야 했다. 그리고 시스템의 리소스를 빌리거나, 반환을 할 때 사용자 식별 하기 위하여 로그인이 필요하였다. 하지만 백엔드, 서버쪽을 구현 할 때 Micro-Service Architecture(이하 MSA)로 동작하기 때문에 항상 서버가 동일한 곳을 접근 한다는 보장이 없었다. 그렇기 때문에 하나의 토큰을 만들어서 발급하고, 해당 토큰이 무결성만 입증한다면 사용을 허가하는 방식으로 방향을 잡았다.
ERP를 만들면서 JWT는 어디에 사용할 것인가?
ERP 시스템을 만들면서 JWT는 RaspberryPi, 키오스크에서 장비를 빌리거나, 반납 할 때 임시적인 로그인 토큰을 발급하기 위함이며, ERP 메인 서버와 관리자를 위한 웹 서버에서 로그인 할 때 사용할 예정이다.
JWT가 아닌 다른 방식으로 구현을 생각 하였지만 로그인을 위하여 Mysql Cluster나 DB 클러스터링을 공부하고, 적용하기에 많은 어려움이 있기에 토큰 자체에 정보가 담겨있으며, 무결성까지 입증이 가능한 JWT를 선택하게 되었다.
MSA가 무엇인가?
기존에 모노리즘 아키텍처를 활용하여 개발을 진행 하였지만 컨테이너 기술이 발전함으로 써 MSA 라는 아키텍처가 나오게 되었다. 장,단점은 확실히 있지만 k8s를 사용하기 때문에 자연스럽게 MSA를 사용하게 되었다.
모노리즘 vs MSA
MSA의 가장 큰 단점으로는 테스트를 자동화 하기가 매우 어렵다는 점이고, 잘못된 마이크로서비스를 배포하게 될 경우 모든 시스템이 중단이 되는 문제점이나, DDoS나 시스템이 과부하가 되었을 때 하나의 시스템이 죽게 된다면 다른 시스템에 부하가 더 가해지게 되면서 모든 시스템이 중단이 되는 문제가 발생할 수 있다.(모노리즘으로 해도 똑같을것 같긴하다…)
MSA에서 왜 JWT를 사용하는가?
기존 모노리즘 아키텍처를 사용한다면 중앙에 인증 서버를 하나 둔 다음 모든 시스템이 인증, 무결성 검사를 진행 해야 했었다. 정보 자체를 검사하고 입증을 해야하며, 상태를 가지고 있는 Stateful 형식이다. 하지만 MSA는 모든 시스템, 서비스는 모듈화가 되어있으며, 통신 장애와 서버 부하가 있을 때 어떻게 데이터를 유지할지, 데이터베이스 서비스와 어떻게 통신을 해야하는지 정의를 해야 했었다. 그렇게 진행이 된다면 하나의 시스템이 Scale-Out이 된다면 데이터베이스도 Scale-Out이 되면서 결국 모든게 성능에 부하를 주게 될 수도 있다. 그래서 나온것이 데이터 자체가 서버에서 만든것임을 무결성 입증만 된다면 옳바른 사용자라고 인식하는 기법이 나온것이다.
JWT가 무엇이길래?
JWT는 Json Web Token이라는 의미를 가지며 Json 형식의, Web에서 사용하는 Token이란 의미이다. Json을 이용하여 Token에 정보를 저장하는 기법이다. 총 3개의 데이터가 정의가 되어 있다.
- Header : Token의 타입, 형식을 나타낸다.
- Payload : 실제 서버에서 주고받는 데이터를 담는다.
- Signature : 서버에서 무결성 검사를 위한 데이터
3가지의 데이터를 가지고 있으며 테스트를 위한 사이트도 있다.
JWT는 어떤 형식을 가지는가?
Header와 Payload의 데이터는 Base64 인코딩이 하며 마지막의 Signature은 Header + Payload + Secret Key를 합친 뒤 해싱을 통한 나온 데이터를 사용한다. 그리고 Header와 Payload와 Signature의 데이터 구분은 “.” 으로 한다.
JWT에서 가장 큰 실수를 범할수도 있으며, 오류가 발생이 가능한 부분이 있다. 바로 Base64와 HTTP 통신이다. Base64에서 인코딩할 때 Padding 데이터를 추가하게 되면 “=” 데이터가 나타나게 되는데 “=” 데이터는 HTTP 통신에서 다른 용도로 사용하는 값이기 때문에 오류가 발생할 수 있다.
예로는 https://example.com/index.html?aaaa=bbbb 이다. aaaa 란 변수에 bbbb란 데이터를 넣는 Key-Value 형태이다.
그렇지만 Base64에서는 Encoding 할 때 나오는 “=” 데이터는 결국 Padding 데이터이며, 실제 Decoding을 할 때는 “=”이 없어도 정상적으로 동작한다.
장점
- 토큰 자체가 의미를 갖는 Claim 기반 토큰 방식
- 서버에서 따로 인증 서버를 만들 이유가 없음. (비용의 절감)
- Secret Key만 있다면 무결성 입증이 가능 함.
- 트래픽에 대한 부담이 적음.
- Scale-Out하기 매우 편하다.
단점
- Secret Key가 탈취 당한다면 모든 서버가 무력화 됨.
- 사용자가 Token이 탈취 당했다면 만료가 될 때 까지 해킹이 되어야 한다.
- 사용자가 매번 로그인을 해야 한다.
- 중요한 데이터를 Token에 담을 수 없다.
그 외에 공부해서 알고 있지만 적기가 매우 귀찮은 내용
- Refresh Token을 활용한 Access Token 재발급
- 그래서 왜 세션 종료 1시간! 같은 개념이 나오게 되었는지 알게 됨.
- HMAC (Hash-based Message Authentication Code)를 이용해서 데이터 무결성 검사하는 기법을 알게 됨.
- 아이디와 패스워드가 해킹을 당하는것 보다 Token이 탈취되면 적어도 기간제 해킹이 된다.
- JWT는 Stateless의 상태가 없는 토큰이지만 실제로는 Refresh Token과 같은건 Stateless 같은 Stateful로 구성이 되는 경우가 많다.
- HMAC이 아닌 다른 방식으로도 Token의 무결성 검사가 가능하며, 다양한 인증 기법이 있다.
- 결국 모든건 HTTP 통신은 취약하므로 HTTPS를 이용 해야 하며, 사용자단 데이터 탈취는 막지 못한다.
- 아이디와 비밀번호 보다는 토큰 탈취 되는게 일단 더 안전하니까..~!