JWT (JSON Web Token)

http 프로토콜은 상태(state)를 유지하지 않는 stateless protocol.

요청(request)를 전송하고 응답(response)를 전송받은 시점에서 통신이 종료되며 어떠한 상태 정보도 남지 않는다.

 

즉, 특정 클라이언트에서 동일 서버에 반복하여 접속하여도 각각의 접속은 독립적인 트랜잭션으로 취급된다.

따라서 로그인 화면에서 아이디, 패스워드를 입력하여 사용자 인증 과정을 거친 이후에 재차 웹사이트에 접근하면 로그인 상태임을 인식(유지)할 수 없으므로 매번 사용자 인증 과정을 반복해야 하는 문제가 발생한다.

 

-http 프로토콜의 상태 비유지(stateless) 문제를 보완하기 위해

-클라이언트와 서버 간의 논리적 연결을 유지하기 위해

1) Session, 2) Cookie, 3)Cookie-Based Session 방식과 같은 stateful 서버가 있다.

 

 

내가 그렸다.

 

 

stateful 서버는 요청이 있을 때 마다 클라이언트의 상태를 유지.

stateful 서버는 인증에 성공하였을 때 즉 인증 상태 정보를 서버의 메모리 또는 데이터베이스에 유지하고 서비스 제공에 사용한다.

 

JWT(JSON Web Token) 기반 인증(토큰 기반 인증)은 상태를 서버에 유지하지 않는다.

즉, stateful 서버와 반대적 개념인 stateless 서버를 사용하며 상태 정보를 유지하지 않는다.

 

토큰 기반 인증은 일반적으로 아래의 방식으로 구현한다

1) 클라이언트 : 아이디와 패스워드로 사용자 인증을 요청

2) 서버 : 사용자 인증. 인증 성공시 정상적으로 발급된 토큰임을 증명하는 signature를 갖는 토큰을 클라이언트에 발급.

3) 클라이언트 : 토큰을 저장, 서버 요청시 해당 토큰을 요청 헤더(Request header)에 담아 서버에 전달.(이거 보안상 위험하다는 거 아니었나?)

4) 서버 : 토큰 검증, 요청 응답.

 

 

내가 그렸따.

 

 

장점이라고 알려진 바로는

토큰 기반 인증은 상태 정보를 유지하지 않기 때문에 서버 확장성(Scalability)이 좋다.

클라이언트는 쿠키를 전달할 필요가 없으므로 보안성이 강화된다.
(쿠키 저장 공간에 잘 들어가 있던데??? 그러나 전송방식에 차이가 있다는 카더라가 있다.)

다른 서버의 서비스에 정보를 공유할 수 있는 장점이 있다.

 

---

트러블 슈팅 : 하나도 안와닿는다!!!

1. 1주차 프로젝트에 사용했던 Session 코드

 

2. 다른 Cookie 코드

 

3. 1주차 프로젝트에 사용했던 JWT 코드

 

확인해볼 것.

 

---

실제로 겪었던 트러블 슈팅 : 인코딩 디코딩 문제

https://inmanustuaspater.tistory.com/manage/newpost/14?type=post&returnURL=https%3A%2F%2Finmanustuaspater.tistory.com%2F14 

https://inmanustuaspater.tistory.com/manage/newpost/14?returnURL=https%3A%2F%2Finmanustuaspater.tistory.com%2F14&type=post

해당 포스팅에 정리되어 있다.