spring 강의에서 싱글톤 방식의 주의점 부분에서 강사님이 이렇게 말한다.
객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면 안된다. 무상태(stateless)로 설계해야 한다! 스프링 빈은 항상 무상태(stateless)로 설계하자.
stateful과 stateless 개념, 그리고 다양한 인증방식에 대해 정리해보려고 한다!
클라이언트와 서버 관계에서 서버가 클라이언트의 상태를 보존함을 의미한다.
클라이언트의 이전 요청이 서버에 전달되었을 때, 클라이언트의 다음 요청이 이전 요청과 관계가 이어지는 것을 의미한다.
클라이언트 : 딸기 한박스 나중에 주문할게요
서버 : ok
(3일 뒤)
클라이언트 : 저번에 그거 주세요
서버 : 딸기 한박스 전송!
무상태! 상태를 유지하지 않는다. 이전에 요청한 정보에 대해서 서버는 알 수 없다.
클라이언트 : 딸기 한박스 나중에 주문할게요
서버 : ok
(3일 뒤)
클라이언트 : 저번에 그거 주세요
서버 : ? 그게 뭐야
이러한 stateful과 stateless 개념은 웹, 앱 서버 개발 시 사용자 인증 방식을 결정할 때에도 활용된다.
http://<userId>:<password>@www.naver.com
-> 매번 인증해야 한다는 단점이 존재한다.
-> Browser 내에 사용자 정보를 저장해 놓고 상태를 유지시켜 놓기 때문에
해킹당할 수 있는 위험이 존재한다.
stateful!
쿠키 방식의 경우 서버는 특정 클라이언트가 무엇을 주문했는지 기억하지 않고 클라이언트가 저장되어 있는 이전 데이터를 불러와 반복적으로 서버에게 요청한다.
세션의 경우 특정 클라이언트가 무엇을 요청하는지 서버에 저장되어 있어 요청에 대한 응답을 실행한다.
서버가 여러개이면, 사용자마자 본인의 세션 ID가 저장되어 있는 서버를 찾아야하는 번거로움이 발생한다.
접속자가 많아지면, 세션ID 요청이 엄청나게 많아질 것이고 서버에 과부하가 올 수 있다.
이러한 문제점을 해결하기 위해서 토큰 방식이 등장한다!
JWT (Json Web Token)
장점 : 토큰으로 상태관리를 하기에 따로 세션을 둘 필요가 없다.
하지만! 토큰도 탈취당할 수 있기 때문에 토큰 관리를 해야한다.
(Access Token, Refresh Token)
다른 웹사이트 상의 자신들의 정보에 대해 접근 권한을 부여할 수 있는 공통적인 수단 개방형 표준