JWT - JSON Web Token 이란 - 개념

JWT - JSON Web Token 개념

 

1. 전통적인 웹어플리케이션 기본 구조 

 

 

전통적인 웹프로그램의 구조는 위 그림과 같다.  

 

 

문제점 1 - 이용자가 늘어나서 서버 등 장치를 더 늘려야 된다면?

 

클라이언트는 문제가 안된다. 웹어플리케이션도 문제가 안된다.

Api server 도 스케일 아웃해서 늘리면된다. 

문제는 Database 다. 스케일 아웃 해서 병렬처리 하면되는데, 비용이 많이 든다.

 

 

그래서 가장관리하기 귀찮은 데이터 베이스를 지울 수 있다면?

 

 

유저 데이터를 유저(클라이언트)가 직접관리하게 한다. 

유저가 데이터를 볼 수는 있지만 수정은 불가능하다.

수정은 서버만 수정 할 수 있다.

 

JWT를 이용한 웹애플리케이션 구조

 

 

JWT를 이용한 웹애플리케이션 구조는 위와 같이 생겼다. 즉, 클라이언트에 필요한 유저 정보를 저장한다.

 

 

 

2.세션 기반 인증 방식 - (전통적인 방식)

 

서버가 인증을위한 SessionID를 관리한다.

클라이언트는 SessionID를 cookie에 가지고 있다가 서버로 전달한다.

 

 

1.클라이언트가 Id/Password 를 이용해서 가입하고 로그인 한다.

2.server에 sessionID 가 생성되어 저장된다.

3.서버는 sessionID를 cookie에 저장해서 클라이언트에 응답한다.

4.클라이언트가 다음에 요청할때 cookie에 담겨있는 Session ID를  server에 요청하면

server는 로그인이 되었을때만 볼 수 있는 특정 페이지를 보여준다.

 

 

문제점 1 - 만약 서버가 여러개로 늘어난다면?

 

서버가 여러개로 늘어난다면 각각 서버마다 SessionID를 관리해야해서 비효율적이고 까다롭다.

이와 같은 문제를 해결하기 위해서 JWT를 사용한다. 

 

중요: JWT는 session 상태를 관리하지 않는다. (Stateless)

 

 

 

 

1.클라이언트가 서버에 Id/pw를 입력해서 요청한다.

2.서버는 클라이언트에게 token을 넘겨준다.

3.클라이언트는 token을 이용해서 요청한다.

4.서버는 sessionId를 관리하지 않는다. 클라이언트가 보낸 토큰을 검증만 할 뿐이다. 검증을 해서 맞으면 권한을 부여한다. 

5.클라이언트는 token을 이용해서 다른 서버에 요청을 보낼 수 도 있다. 

 

 

3.JWT 형식

 

 

1.서버가 토큰을 발급하고 클라이언트가 token을 서버에 전달할때는 Encoded 형태로 전달해준다.

2.빨간색 부분은 헤더, 자주색 부분은 페이로드(본문) , 하늘색 부분은 시그니쳐 부분(헤더+페이로드+시크릿키)이다.

 

 

Header : 어떤 타입 데이터, 어떤 암호화 알고리즘 정의

Payload : 실제 전달될 데이터

Signature : 클라이언트에서 건들 수 없다. 

관리는 서버에서 한다. 유저가 payload를 임의로 조작해서 보낸다면 서버에서 header와 payload를 이용해서 signaure를 만들고 클라이언트가 보낸 signature를 이용해서 검증한다.