Session 기반 인증 방식이란?
사용자의 상태 정보(로그인 여부 등)를 서버에 저장하는 Stateful 상태 유지 방식이다.
세션은 클라이언트가 서버에 요청을 한 시점이 언제인지에 따라서 동작이 달라진다.
가장 흔하게 사용되는 로그인 동작을 기반으로 "세션"의 동작에 대해 소개한다.
세션 동작 방식
최초 요청 (로그인)
“클라이언트” → 로그인 정보를 서버에 전달 (ID: User, Pw: 1234)
“서버” → DB에서 아이디/패스워드를 검증 후 User 전용 “세션 저장소”를 생성.
해당 저장소에는 이 사람은 User이고 “관리자” 권한이 있다.. 등의 정보를 저장함
“서버” → 클라이언트에 반환할때 header의 Set-Cookie에 session-ID를 담아서 반환
“클라이언트” → 응답 헤더의 Set-Cookie를 보고 Session-ID(1234)를 쿠키 저장소에 보관
두 번째 이후 요청 (인증)
“클라이언트” → “마이페이지”와 같은 인증이 필요한 페이지 리소스를 요청. 이 때 로그인 ID/PW가 아닌 Session ID를 전송 (두 번째 부터 클라이언트는 아이디, 비밀번호가 아닌 세션 아이디를 전송.
왜냐하면 로그인한지 10초도 안됐는데 인증이 필요한 페이지에 들어갈때마다 서버가 아이디, 비밀번호를 요청한다면 서버도 그만큼의 비용이 발생하고, 클라이언트 또한 매우 불편하기 때문)
“서버” → 클라이언트 측에서 전달한 세션 아이디를 기반으로 사용자 검증
“서버” → 마이페이지 HTML 반환
세션은 언제 사라지는가?
#1 사용자가 로그아웃 했을 때
→ 사용자가 로그아웃 버튼을 누르면 서버는 세션 저장소에서 사용자의 세션 데이터를 제거
#2 타임 아웃
→ 아무런 요청을 하지 않고 보통 30분이 지나면 서버는 세션 저장소에서 해당 데이터를 자동 삭제
#3 브라우저 종료
→ 이는 세션 쿠키 방식에 따라서 달라지는데, 만약 서버가 만료시간 (Expires, Max-Age) 을 설정하지 않으면 해당 쿠키는 ‘세션 쿠키’가 된다. 이 쿠키는 브라우저가 닫힐 때 사라짐
만약 서버가 해당 쿠키를 “한 달간 로그인 유지”처럼 길게 설정하면 영구 쿠키 (Persistent Cookie) 가 되어 브라우저를 닫았다가 켜도 남아있음.
세션 쿠키 (Session Cookie)는 "로그인 상태 유지" 혹은 "임시 데이터" 등에 사용되어 브라우저 메모리에 저장되고
영구 쿠키 (Persistent Cookie) 또한 다양한 상황에서 사용되며 주로 웹 사이트의 "ID저장" 기능이나 "오늘 하루 팝업 보지 않기" 같은 기능에 사용된다.
세션 방식의 단점
여러 대의 서버 (WAS1, WAS2, …) 가 있을 때는 세션 불일치 (Session Consitency) 문제가 발생한다. 만약 사용자가 WAS1에서 로그인하고 세션을 발급 받았는데 로드 밸런서를 통해 WAS2로 요청이 전달된다면 WAS2에는 해당 사용자의 세션 정보가 없기에 “로그인되지 않은 사용자”로 분류할 것이다.
해결 방법
#1 Sticky Session
로드 밸런서에게 이 사용자는 WAS1으로만 보내라고 설정하는 방식
단점 : WAS1이 다운되면 해당 서버에 붙어있던 모든 사용자의 세션이 날라간다.
#2 Session Clustering
모든 WAS 서버에 실시간으로 세션 정보를 복제, 공유하는 방식
단점 : 서버가 많아질수록 세션 복제에 드는 통신 비용, 부하가 기하급수적으로 늘어난다.
#3 Session Stroage 분리
현대 프로그래밍에서 가장 많이 채택하는 방식으로, 모든 WAS가 공유하는 별도의 세션 저장소를 둔다.
단점 (HDD/RDBMS를 사용하는 경우) : 모든 요청마다 DB에 접근하면 Disk I/O (물리적으로 회전하고 헤더가 움직여야 하는 기계적 디스크 I/O) 가 발생해 성능이 저하된다.
따라서 공유 세션 저장소는 하드디스크가 아닌 메모리 기반 데이터베이스 (RAM 기반) 를 사용해 순차 접근이 아닌 랜덤 메모리 접근으로 전기적 신호로 메모리에 접근하도록 설정해 I/O비용을 낮춘다.
이러한 대표적인 RAM 기반 데이터베이스로 Redis가 존재한다.