[WEB] 세션 기반 인증 및 인가 (feat. 세션 & 쿠키)

공부하게 된 계기

인증 인가를 구현할때 대표적으로 두 가지, 세션 기반 그리고 토큰 기반(JWT 토큰)이 있다. 기존에 창업팀에서 개발을 할때 인증 및 인가를 JWT 토큰을 통해 구현했다. 그 이유는 바로 "구글링 했을 때 사람들이 많이 쓰는 것 같으니까. 그냥 좋아 보여서." 라는 이유 였다. 잘못됐다. 각각의 구현 방식에 대해 이해하고 장단점을 파악하고 그거에 맞게 하나를 선택해야 했지만 그렇지 못했다. 그래서 이제라도 세션을 통한 인증 및 인가에 대해서도 공부해야할 것 같아서 알아보게 됐다.

 

 

세션 기반 인증 인가 도입 이유

HTTP는 Stateless와 Connectionless라는 특징을 가지고 있다.

HTTP Stateless

HTTP(Stateless Hypertext Transfer Protocol)는 상태를 유지하지 않는 프로토콜입이다.
이는 HTTP 서버가 클라이언트의 이전 요청 상태를 기억하지 않고, 각각의 요청이 독립적으로 처리된다는 것을 의미한다.
클라이언트가 서버에 요청을 보내면, 서버는 그 요청에 대한 응답을 생성하고 클라이언트에게 전송한다. 그러나 서버는 클라이언트의 이전 요청에 대한 정보를 유지하지 않는다. 이러한 상태 없음의 특성은 서버의 확장성을 높이고, 서버의 부하를 줄이는 데 도움이 된다. 왜냐하면 각각의 요청을 독립적으로 처리할 수 있기 때문이다.

HTTP Connectionless

요청이 발생하고 그에 대한 응답이 발생한 뒤 TCP/IP 연결 종료됨.

HTTP 프로토콜은 클라이언트에서 서버에 요청(Request)을 보내면 서버는 클라이언트에 응답(Response)을 하고 연결을 끊는 특징을 가지고 있다. 바로 TCP / IP 연결을 끊어서 해당 커넥션을 유지하지 않는다. 이러한 비연결성으로 인해 매 요청마다 TCP / IP를 새로 맺어야 하기 때문에 낭비가 발생할 수 있다. 
그러나 HTTP1.1부터 Connection Header의 keep-alive를 통해 한 번의 TCP 연결을 사용하여 여러 HTTP 요청과 응답을 처리할 수 있도록 한다.

 

세션 쿠키는 HTTP 프로토콜의 위 두가지 특징(단점)을 보완하기 위해 사용!

 

따라서 서버와 클라이언트가 통신을 할 때 연결이 발생하고 한 번의 요청과 그 요청에 대한 응답이 돌아오게되면 연결(통신)이 종료된다.
또한 연결(통신)이 종료되면서 상태 정보가 날라가기 때문에 매번 페이지를 이동할 때마다 인증을 다시해야하거나 예를 들어 구매하고자 하는 상품을 장바구니에 담고 결제 페이지로 넘어 갔을 때 장바구니가 초기화되는 문제들이 발생한다.

 

이러한 문제를 해결하기 위해 쿠키와 세션이 사용된다.

쿠키는 클라이언트 측에서 상태 정보를 저장하고 유지하여 클라이언트의 이전 상태를 추적할 수 있게 한다.

세션은 서버 측에서 클라이언트의 상태 정보를 유지하고 관리하여 상태 정보를 보다 안전하게 관리할 수 있게 한다.

세션 및 쿠키에 대해서 조금 더 자세히 알아보자

 

세션 기반 인증 인가 프로세스 

세션 기반 인증 인가

이 프로세스는 노마드 코더님의 강의를 바탕으로 정리해봤다.

`Nico`라는 유저가 서비스에 로그인 하고 싶다면 유저명과 비밀번호를 서버에 보낸다. 이 과정이 인증을 요청하는 것이다. 이때 유저명이 아닌 ID가 될 수도 있고 이메일이 될 수도 있다. 이때 비번이 유효하다면 세션 정보(`Nico`)를 데이터베이스에 저장한다. 이때 해당 세션 보다 고유한 식별자인 Session ID가 있다. 해당 세션 ID는  쿠키에 담겨서 브라우저로 돌아오고(응답) 저장된다.

브라우저는 추후에 요청을 보낼때 세션 ID가 포함된 쿠키를 서버로 보내게 된다. 그러면 서버는 세션ID가 있는 쿠키를 지닌 요청이 들어온 것을 알게 된다.

해당 쿠키의 세션 ID가 서버의 세션DB를 통해 검증한다. `Nico`라는 유저는 인증에 성공하여 세션DB에 세션ID 등 세션 정보 등잊 저장 되었으므로 해당 세션 ID를 통해 유저명이 `Nico`라는 것도 알 수 있다.

이러한 과정이 해당 웹 서비스의 매 페이지를 접속할때 마다(매 요청 마다)세션 ID가 포함된 쿠키와 함께 요청을 보내고 그것을 검증하는 과정이 반복된다.

중요한 유저 정보는 모두 서버 단에 있다. 클라이언트 단에서는 세션 ID만 보유할 수 있다.
그래서 쿠키는 단지 세션 ID를 전달하기 위한 매개체일 뿐이다.
그러나 쿠키는 네이티브 앱에는 없다. 브라우저에만 존재하는 개념이다.

 

매 요청이 끝날 때마다 서버가 클라이언트의 상태를 유지하지 않는 HTTP의 Stateless 및 Connectionless 특성을 위와 같은 메커니즘을 통해 극복 가능하다. 

 

장점

서버는 로그인 된 유저의 모든 정보를 저장하기 때문에 이를 통해 다양한 기능들을 구현 가능하다.

• 로그아웃이나 특정 유저를 강제 로그아웃 시켜야할 경우 그냥 세션을 삭제하면 된다.
• 인스타그램처럼 로그인된 모든 디바이스를 조회할 수 있도록 하고 특정 디바이스로 부터 강제 로그아웃 시킬 수 있다.
• 넷플리스처럼 계정 공유 숫자 또한 제한 가능하다.

단점

• 장점에서 언급한 듯이 로그인한 모든 회원을 세션 DB에 저장하기 때문에 DB를 사고 유지해야한다. 또한 유저가 많아질 수록 더 큰 DB가 필요하고 주로 Redis가 사용된다.
• 또한 매 요청마다 쿠키의 세션 ID 값을 세션 DB에 접근해서 검증하는 과정을 거쳐야하기 때문에 유효성만 검증하면 되는 토큰 기반 인증 인가 구현 방식에 비해 성능 이슈를 겪을 수 있을 것이다.