[JWT] JWT & SpringBoot에 Security 설정 & 커스텀 Filter 추가

▷ 인증 방법 3가지

1.  세션 기반 인증 (서버 기반 인증)  -  하나의 도메인에서 사용할 때

: 만약 유저가 로그인을 하게 되면, 서버 측에서 유저가 현재 로그인 중이라는 인증정보를 기억하고 있어야 한다. 

이 정보를 세션이라고 부른다. 

세션을 유지하기 위해서는 메모리, 디스크, 데이터베이스 시스템 등에 담아둔다. 

하지만 이러한 방식은 큰 규모의 어플리케이션을 개발하기에 어려움이 있다. 

 

※ 스프링 시큐리티도 세션 기반 인증이다. 

 

※ 세션에는 객체를 저장할 수 있지만, JWT는 문자열 타입만 저장할 수 있다. 

 

※ 세션 기반 인증의 문제점 2가지 

✔️ 세션을 유지하게 될 때, 로그인 중인 유저가 많아지면 메모리 또는 디비의 성능에 무리가 간다. 

✔️ 서버 확장이 어렵다. 세션을 사용하면서 분산된 시스템을 설계하는 건 ,

세션의 정보가 분산된 프로세스 간에 동기화가 되어야 한다는 의미이므로 매우 복잡하다. 

✔️ 그럼 왜 서버 확장이 어려울까??👇🏻

: 세션도 결국엔 쿠키 방식을 이용하는 것인데 (JsessionID를 쿠키에 전달)

쿠키는 같은 서버로 보낼 때만 전달이 되는 것이기 때문이다. 

 

 

MPA 방식은 각각 서버마다 로그인, 인증 처리를 해야 하고, 

SPA 방식은 하나의 서버만 로그인해도 JWT만 가지고 오면 로그인 여부를 알 수 있다. 

 

2. JWT 이용  -  인증 허가하는 서버와 인증을 사용하는 서버가 다를 때 

1. 토큰 기반 시스템은 세션과는 다르게 stateless하다.

즉, 서버에서 유저의 정보를 유지하지 않고, 유저가 인증을 할 때,  토큰을 발행해준다. 

발급된 토큰은 유효기간, 유저 정보 등을 담고 있으며 해싱 알고리즘을 통해 인증이 되어 있어서(???)

서버에서는 검증을 통하여(???) 처음 서버가 발급해주었던 정보가 변조되지 않았음을 보장해 줄 수 있다. 

 

2. 토큰을 사용함으로서, 서버를 확장하게 될 때에 매우 용이해진다. 

서버 시스템이 분산되어 있어도, 유저는 같은 토큰으로 서버에 요청을 하면 되고,

서버는 그저 그 토큰이 위조되지 않았는지만 검증을 하고, 디비 조회를 할 필요 없이 바로 인증된 유저임을 알 수 있다. 

 

2-2. JWT 확장   - 프록시 서버

✔️ Proxy 서버 : 클라이언트 입장에서는 서버는 하나이다. 즉, 클라이언트는 프록시 서버의 포트 번호 하나만 알면 된다.

그러나 요청 내용에 따라서 프록시 서버에서 여러 서버로 요청을 보낼 수 있다. 

프록시 서버 뒤에 스프링 서버, 노드 서버 등이 있어도 JWT와 NGINX를 이용하면 된다. 

✔️ NGINX를 이용해서 서버를 구축하려면 리눅스 환경이어야 한다. 

3. 세션 저장소 이용 - JWT (X)

✔️ 세션 저장소 : 세션만 저장하는 디비를 만들어야 한다. 

 

---

▷ JWT (JSON Web Token)

jwt.io

JWT.IO

[구성 요소]

1. Header : Algorithm & Token Type

2. Payload : Data 

3. Verify Signature

---

▷ Spring Security + JWT Filter 등록하는 방법 (☆☆☆)

1. JWT를 통한 인증을 위해서 필터 객체 구현하기 

-> Authentication 객체 생성 

여기서 Authentication이란 ? (중요) 👇🏻참고 

angelatto.tistory.com/36

[Spring] 스프링 시큐리티 구조 - 1

 

2. 스프링 시큐리티 필터 체인에 새로운 필터 등록 

3. JWTUtils로 인증, 인가 처리