[Network] 쿠키와 세션을 이용한 로그인 방식 (인증/인가)

 

[Network] 쿠키(Cookie), 세션(Session) 그리고 JWT(JSONWebToken) - (1) HTTP

[Network] 쿠키(Cookie), 세션(Session) 그리고 JWT(JSONWebToken) - (2) 쿠키와 세션

 

 

앞의 2개의 글을 통해 HTTP는 비연결성, 비상태성의 특성을 지니기 때문에 서버는 클라이언트가 로그인했더라도 이후 요청 때 해당 클라이언트의 로그인 여부를 확인하기 어렵다는 것을 알 수 있었습니다. 하지만 쿠키와 세션을 활용한다면 로그인 상태를 유지할 수 있게 됩니다. 

 

 

쿠키와 세션을 통한 인증(Authenticaiton)과 인가(Authorization)

인증 (Authentication)

인증은 사용자가 누구인지 확인하는 절차입니다. 회원가입과 로그인 과정이 인증의 대표적인 예시입니다.

예를 들어, 유저가 로그인을 통해 자기 계정을 사용하려 한다면 인증 과정(잠시 멈춰서 검증함)을 거쳐서 회원이 확인되면 로그인시킵니다.  쿠키와 세션 방식을 이용할 경우에는 인증에 성공하면 Session ID를 전달받아 쿠키에 저장하게 됩니다. 

 

인가 (Authorization)

인가는 사용자가 요청 Request 하는 것에 대한 권한이 있는지를 확인하는 절차입니다.

인증을 받은 사용자가 서비스를 이용할때, 쿠키와 세션 방식을 이용할 경우 Response를 보낼 때 Cookie의 Session ID를 담아 보내는데 서버는 Session ID 를 대조해서 이 유저가 로그인 한 사용자라는 것을 알아보고 사용 허가 (인가)를 내줍니다. 

 

세션을 통한 인증, 인가(auth)의 절차

 

1️⃣  클라이언트가 로그인을 하면 서버는 회원정보를 대조하여 인증 Authentication을 합니다. 

 

2️⃣  회원 정보(클라이언트 정보)를 서버의 세션 저장소에 생성하고 Session ID를 발급합니다.

 

3️⃣  HTTP Response Header의 Set-Cookie에 발급한 Session ID를 담아서 클라이언트에 보냅니다.

 

4️⃣  클라이언트에서는 Session ID 를 쿠키 저장소에 저장하고 이후에 HTTP Request를 보낼 때마다 Header의 Cookie에 Session ID를 담아서 보냅니다. 

 

5️⃣  서버에서는 쿠키에 담겨서 온 Session ID에 해당하는 회원정보를 세션 저장소에서 가져옵니다. Authorization

 

6️⃣  응답 메시지에 회원 정보를 바탕으로 처리된 데이터를 담아서 클라이언트에 보냅니다.

 

 

 

다시 한번 정리 합시다! 👏

 

 

 

사용자가 로그인을 하면 서버는 Session ID를 쿠키(Set-Cookie)로 클라이언트에게 보냅니다. Response

클라이언트는 Session ID를 요청시마다 header의 Cookie에 담아 보내면 서버는 Session ID에 해당하는 클라이언트 정보를 서버의 세션저장소에서 가져옵니다. 이를 통해 클라이언트 정보에 따라 맞춤으로 응답을 할 수 있게 됩니다.

 

세션 저장소를 사용하여 사용자 데이터를 저장해야 되기 때문에 추가적인 저장공간을 필요로 하다는 단점이 있습니다. 

 

하지만 Session ID만 쿠키에 담겨서 요청을 보내기 때문에 요청 때마다 사용자 정보를 쿠키에 담아서 전송하는 것보다 안전합니다. 하지만 Session ID를 사용하는 방법이 완전히 안전한 것은 아닙니다. 악의를 가진 😈 해커 😈 가 Session ID를 알아내서 이를 가지고 서버에 요청하면 서버는 구별해 낼 수 있는 방법이 없습니다. 이를 Session Hijacking 이라고 합니다. 해결책으로는 HTTPS를 사용하여 암호화하거나 Session의 만료시간을 짧게 설정하는 방법이 있습니다. 

 

또한 세션과 쿠키를 이용한 로그인 방식은 Load Balancing 및 서버 효율성 관리 및 확장이 어려워질 수 있다는 단점이 있습니다. 

왜냐면 여러 대의 서버를 사용하는 시스템의 경우, 유저 로그인 시 해당 유저는 처음 로그인 했던 서버로만 요청을 보내도록 설정해야 하기 때문입니다.

 

 

 

Load Balancing 로드 밸런싱

애플리케이션 서버와 방문자 또는 클라이언트 간의 인터넷 트래픽을 지시하고 제어하여 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법입니다.
결과적으로 애플리케이션의 가용성, 확장성, 보안 및 성능이 향상됩니다. 

 

 

 

 

위의 인증/인가 방식은 세션과 쿠키를 이용한 방식이지만, 토큰 Token 또한 인증/인가 방법 중 하나입니다. 가장 대표적인 토큰 기반 인증 중 하나가 JWT(JSON Web Token) 을 이용한 방법입니다. 그렇다면 세션&쿠키 방법과 토큰 방법 중 어떤 것을 사용하는 것이 좋을까요? 이 질문에 답하기 위해 토큰이 나오게 된 배경을 살펴봅시다. 

 

 

왜  토큰 기반의 인증을 사용해야 할까? 

토큰 기반 인증 방식은 세션 기반의 인증 방식의 단점을 보완하고자 등장하게 되었습니다. 하지만 그렇다고 토큰 기반 인증 방식이 무조건 세션 기반 인증 방식보다 좋은 것은 아니고 각각 장단점이 존재합니다. 프로젝트의 규모와 특성에 맞게 선택하면 됩니다.

 

세션 기반 인증 방식은 위에서 살펴봤듯이 유저가 로그인하면 로그인 된 사용자들에 대한 정보들을 백엔드의 세션 스토리지에서 유지하고 있는 형식입니다. 세션 기반 인증 방식을 이용하게 되면 Session ID를 사용하기 때문에 백엔드 서버에서는 유저들의 로그인 여부를 파악하기 쉽고, 유저에 대한 데이터가 클라이언트의 조작에 영향을 받기 어렵다는 장점이 있습니다. 

 

하지만 세션을 통해 관리하게 되면 세션 저장소 자체가 백엔드 서버에서 관리하고 있기 때문에 백엔드가 무거워지게 된다는 문제가 있습니다. 특히, 서버를 확장해야 하는 상황이 왔을 때, 매우 곤란해집니다. 

서버 한 대 내에 존재하던 세션 스토리지가 여러 대로 늘어나게 되면, 세션 관리를 서버마다 따로 해줘야 하기 때문입니다. 

이를 해결하기 위해 Sticky Session 방식 또는 세션 클러스터링 방법을 이용할 수 도 있고, 세션 서버를 Redis에 따로 두어 세션 저장소 관리해야 합니다. 

 

머리가 아픕니다.

 

이런 세션 저장소가 서버에 종속되있기 때문에 파생되는 피곤한 문제들을 근본적으로 해결하기 위해 만들어진 방식이 토큰 인증 방식입니다. 

 

토큰을 사용하면 사용자 인증 정보를 서버의 세션 저장소에 저장하고 있지 않아도 됩니다. 대신 프론트단에서 역할을 위임하게 됩니다. 

프론트 쪽에서 토큰을 가지고 있다가 인증이 필요한 Request시 토큰을 함께 보내면 됩니다. 

 

아래는 토큰 기반 인증 방식 모식도입니다. 다음 글에서 설명과 함께 자세히 봐볼게요!

 

 

 

 

 

 

 

✅ 평소에 Server 라는 단어를 자주 쓰는데, 관련 자료를 찾아보던 중 Web Server와 Web Application Server를 혼용해 사용하며 많은 사람들이 관용적으로 Server라고 퉁쳐서 사용하는 것을 찾아 볼 수 있었어요. Web Server와 Web Application Server 를 설명한 글이 있어 한번 가볍게 읽고 넘어가면 좋을 것 같습니다. 🔗 링크

 

 

참고 자료

로드 밸런싱이란 무엇인가요?

세션 VS 토큰

[React + Express] JWT를 이용한 토큰 인증 방식 구현하기

세션 클러스트링이란?

세선 기반 인증과 토큰 기반 인증(JWT) 차이점

 

 

 

레디스