들어가기 앞서
이론적인 부분에서는 사실 크게 어려운 부분이 없었다. 하지만 Spring 6버젼부터 기존과 너무 상이해진 문법때문에 어려움이 많았다.
더구나 한글 문서또한 참고할게 없어 찾는데에 많은 어려움이 있었다.
이론적인 부분은 메타코딩의 Spring security 특강을, 코드는
- https://github.com/Java-Techie-jt/spring-boot3-jwt
- https://github.com/Ons-diweni/Spring-Security-6-JWT
위 두 코드를 참고하였다
왜 token?
Http는 Stateless하다
- HTTP의 비연결성(Connectionless)
HTTP는 요청을 주고받을때마다 연결을 종료 후 다시 생성한다 - HTTP의 비상태성(Stateless)
HTTP는 요청을 주고받을때 이전에 보냈었던 정보들을 기억하지 않는다
초기 HTTP는 단순 HTML파일만을 교환하기 위한 요청이였으며, 위같은 특성때문에 빠르게 파일교환이 가능했다
하지만 WEB이 발전함에 따라 상태를 유지할 필요가 생기게되었다
Cookie의 등장
위같은 기능을 위하여, HTTP요청시 Cookie를 함께 전송하며 상태에 대한 정보를 전송하게 되었다
Cookie의 문제점
- 성능문제
Cookie를 통해 정보를 전송하는 기능은 헤더에 다량의 정보를 전송하게 된다
특히Cookie는 보통 4kb의 크기 제한에, 개수또한 20개로 제한(브라우저에 따라 상이)이 되어있다 - 보안문제
Cookie는Client측에 저장되는 데이터이다
기본적으로 만료시간 또는 브라우저 종료시에 삭제되는 데이터이지만, 해커에게 탈취, 변조되기 쉽다는 단점이 존재한다
Session의 등장
Client가 적합한 인증정보를 Server로 전송하였을시, Server는 Session-ID가 담긴 쿠키를 사용자에게 전송하며, Server에서 Session 정보를 담고있다
Java 기반의 WAS들은 JSESSIONID라는 Cookie 정보를 전송한다
이러한 Session 정보가 WAS에 저장된다.
하지만 Clustering을 통해 scale-out을 진행할때 모든 Server에 Session정보를 저장해야한다
또한 redis, Oracle Coherence와 같은 기술들을 통하여 별도의 Scale-out가능한 Session Storage를 두는 것 또한 가능하다
Session의 단점
- Session공유-성능문제
위 설명에서처럼Scale-up된 서버에서 Session을 유지시키기 위한 여러가지 기술들이 들어간다
Weblogic에서는primary-server,secondary-server와 같은 기술등을 통하여 복잡한 로직이 수행된다
token의 등장
위 방법들의 대안으로 token방식또한 존재한다
인증정보를 확인 후, 사용자 정보를 담은(하지만 민감한 정보는 담지 않는다) 토큰을 발행하여 사용한다
위 방법들에 비해 scale-up되는 환경에서 더욱 간단한 인증절차를 통해 사용이 가능하다
token의 단점
- token 탈취
token또한 cookie처럼 유효기간동안은 계속하여 사용이 가능하다
이는 유효기간중 token이 탈취당했을시 심각한 보안문제를 야기한다 - 위변조 가능
token정보는 누구나 decoding, encoding 가능한 정보이기에 민감한 정보를 넣지 않도록 주의해야한다
