2023-03-19
1. 가정
로그인을 진행하려는 "가"라는 유저가 있다. "가" 유저는 프론트 서버의 로그인 버튼을 통해 백엔드 서버에게 유저 정보 확인 후 인증정보를 획득한다. 인증정보를 어떻게 다시 프런트에서 확인하고 인증에 따른 기능을 사용할 수 있는 것일까? 즉 서로 다른 두가지 애플리케이션(프런트 / 백엔드) 어떻게 해당 유저 정보를 공유할 수 있는 것인지 알아보자.
2. tomcat JSESSIONID
우선 톰켓 서버의 JSESSIONID에 대하여 알아야 한다. 이는 톰캣이 구동후 클라이언트가 해당 서버에 최초 접속을 하면 생성되는 쿠키입니다. 해당 쿠키는 세션에 대한 식별자로 사용되며, 세션이 종료되면 제거가 됩니다.
아래는 JSESSIONID 어떻게 생성되는지에 대한 글이니 참고하시면 좋을 거 같습니다.
https://stackoverflow.com/questions/595872/under-what-conditions-is-a-jsessionid-created
Under what conditions is a JSESSIONID created?
When / what are the conditions when a JSESSIONID is created? Is it per a domain? For instance, if I have a Tomcat app server, and I deploy multiple web applications, will a different JSESSIONID be
stackoverflow.com
3. 프론트 서버
백엔드에서 발생한 JSESSIONID를 프론트에서도 확인할 수 있으면, "가"라는 유저의 인증정보를 서로 공유할 수 있다. 즉 백엔드와 프론트 서버가 "가" 유저의 인증객체를 서로 통신하며 활용할 수 있다. 그러면 프론트 서버는 언제 JSESSIONID를 가져오는가? 이는 어렵지 않다. 프론트 서버가 백엔드 서버에 요청을 보낼 때 톰켓은 해당 프론트 서버의 요청이 동일한 세션일 경우 이를 식별할 수 있는 JSESSIONID가 있는지 체크한다. (동일한 도메인 주소 or 아이피일 경우에만 체크한다. 다른 도메인 간에는 체크하지 않는다. ex) loacalhost:8080 -> loacalhost:3000 은 도메인이 같으므로 체크한다. 포트는 구분하지 않는다.) 없을 경우 Header에 JSESSIONID 심어주고 있을경우 따로 추가적인 쿠키를 심지 않는다.
백엔드의 RequestHeader
프론트의 RequestHeader
위의 예시를 보면 모두 동일한 JSESSIONID를 가지고 통신하는 것을 확인할 수 있다.