[인증 및 인가] Cookie / Session / Token

서버가 클라이언트 인증을 확인하는 방식으로는 대표적으로 쿠키, 세션 토큰 3가지 방식이 존재합니다.

이번 포스팅은 쿠키 세션, 토큰이을 만든 이유, 인증 방식에 대해서 알아보겠습니다.

HTTP의 특징과 쿠키, 세션을 사용하는 이유

쿠키, 세션, 토큰 등을 사용해 클라이언트 인증을 확인하는 이유는, HTTP 프로토콜의 특성이자 약점인 Connectionless, stateless한 특성을 보완하는 이유입니다.

https://interconnection.tistory.com/74

기본적으로 HTTP는 Connectionless와 stateless한 특성을 가지고 있습니다.

• Connectionless : 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어버리는 특징
  헤더에 keep-alive라는 값을 줘서 Connection을 재활용하는데, HTTP 1.1에서는 이것이 Default입니다.
  HTTP가 tcp위에서 구현되었기 때문에 (tcp는 연결지향,udp는 비연결지향) 네트워크 관점에서 keep-alive는 옵션으로 connectionless의 연결비용을 줄이는 것을 장점으로 비연결지향이라 합니다.
• stateless : 통신이 끝나면 상태를 유지하지 않는 특징
  연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있습니다.

쿠키와 세션은 위의 두 가지 특징을 해결하기 위해 사용됩니다.

Cookie

쿠키는 Key-Value 형식의 클라이언트(브라우저) 로컬에 저장되는 작은 데이터 파일입니다.

클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트 브라우저에 설치되는 작은 기록 정보 파일과 같습니다.

이는, 각 사용자마다 브라우저에 정보를 저장하니 고유 정보 식별이 가능합니다.

• 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있습니다.
• 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조합니다.
• 클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있음, 하나의 쿠키값은 4KB까지 저장합니다.
• Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있습니다.
• 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송합니다.

Response header에 쿠키가 담겨 있는 모습

Cookie의 구성 요소

• 이름 : 각각의 쿠키를 구별하는 데 사용되는 이름
• 값 : 쿠키의 이름과 관련된 값
• 유효시간 : 쿠키의 유지시간
• 도메인 : 쿠키를 전송할 도메인
• 경로 : 쿠키를 전송할 요청 경로

Cookie 인증 방식

1. 브라우저(클라이언트)가 서버에 요청(접속)을 보낸다.
2. 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다.
3. 이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다. 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별하거나 정보를 바탕으로 추천 광고를 띄우거나 한다.

Cookie 방식의 단점

• 보안에 취약하다. (요청 시 쿠키의 값을 그대로 보내기 때문에 유출 및 조작 당하기 쉬움)
• 용량 제한이 있다.
• 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 공유가 불가능
• Size가 커질수록 네트워크에 부하가 심해진다.

Session

세션은 쿠키를 기반으로 하고있지만, 비밀번호 등 클라이언트의 민감한 인증 정보를 브라우저가 아닌 서버 측에 저장하고 관리합니다.

(서버의 메모리에 저장하기도 하고, 서버의 로컬 파일이나 데이터 베이스에 저장하기도 합니다.)

• 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지합니다.
• 물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능 합니다.
• 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리, 저장 용량을 많이 차지하게 됩니다.
• 즉 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 됩니다.
• 클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는 데 이것이 세션 ID입니다.

간단히 Express를 통해 예시를 작성해 보겠습니다.

let session = {};
app.get('/set-session', function (req, res, next) {
    const name = 'sparta';
    const uniqueInt = Date.now();
    session[uniqueInt] = { name }; // uniqueInt라는 열쇠 생성

    res.cookie('sessionKey', uniqueInt); // uniqueInt를 통해 열쇠를 제공
    return res.status(200).end();
});

app.get('/get-session', function (req, res, next) {
    const { sessionKey } = req.cookies;
    const name = session[sessionKey];
// 클라이언트가 서버에게 자물쇠를 주면, 서버가 열어서 내용을 확인 후 보내준다.
    return res.status(200).json({ name });
});

Session 생성 시 Console로 찍어본 모습

즉, Session 객체는 Key에 해당하는 Session ID와 이에 대응하는 Value로 구성되어 있으며, 이를 접근하기 위해서는 Session ID가 필요합니다.

Session 동작 방식

1. 유저가 웹사이트에서 로그인하면 세션이 서버 메모리(혹은 데이터베이스) 상에 저장된다.이때, 세션을 식별하기 위한 Session Id를 기준으로 정보를 저장한다.
2. 서버에서 브라우저에 쿠키에다가 Session Id를 저장한다.
3. 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session Id를 쿠키에 담아 전송한다.
4. 서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session Id를 비교하여 인증을 수행한다.

Session의 단점

• 쿠키를 포함한 요청이 외부에 노출되더라도 세션 ID 자체는 유의미한 개인정보를 담고 있지 않는다. 그러나 해커가 세션 ID 자체를 탈취하여 클라이언트인척 위장할 수 있다는 한계가 존재한다. (이는 서버에서 IP특정을 통해 해결 할 수 있긴 하다)
• 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다.

Cookie와 Session의 차이점

• 쿠키와 세션은 비슷한 역할을 하며, 동작원리도 비슷합니다. 그 이유는 세션도 결국 쿠키를 사용하기 때문입니다.
• 가장 큰 차이점은 사용자의 정보가 저장되는 위치입니다. 때문에 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용합니다.
• 보안 면에서 세션이 더 우수하며, 요청 속도는 쿠키가 세션보다 더 빠릅니다. 그 이유는 세션은 서버의 처리가 필요하기 때문입니다.
• 보안, 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 sessionid 만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋습니다.
• 라이프 사이클, 쿠키도 만료시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있다. 또한 만료기간을 넉넉하게 잡아두면 쿠키삭제를 할 때 까지 유지될 수도 있습니다.
• 반면에 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제됩니다. 예를 들어, 크롬에서 다른 탭을 사용해도 세션을 공유됩니다. 다른 브라우저를 사용하게 되면 다른 세션을 사용할 수 있습니다.
• 속도, 쿠키에 정보가 있기 때문에 서버에 요청시 속도가 빠르고 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 가집니다.

즉, 보안적인 측면에서는 세션이 좋지만, 사용자의 수 만큼 서버 메모리와 성능에 부하를 주기 때문에 이런 문제를 보완한 토큰 기반의 인증을 사용하는 추세입니다.

Token

Token의 사전적 의미 : 상품권, 교환권

즉, 자유이용권 Ticket이랑 유사하다고 생각하면 알기 쉽습니다. 내가 자유이용권 Ticket을 가지고 있는 사람이라고 인증을 하는 것입니다.

 

Token 기반 인증 시스템은 클라이언트가 서버에 접속하면 서버가 해당 클라이언트에게 인증되었다는 의미로 Token을 부여합니다.

이 토큰은 클라이언트마다 유일합니다. 클라이언트가 서버로 토큰을 보내면 받은 토큰으로부터 인증된 사용자인지 인증 로직을 거쳐 해당 사용자인지 확인합니다.

• 토큰은 클라이언트에 저장되기 때문에 Stateless하며, 서버를 확장(scalability)하기에 매우 적합한 환경을 가지고 있습니다.
• 쿠키가 아닌 토큰을 사용하기 때문에 보안성이 더 좋습니다.
• 로그인 정보가 사용되는 분야를 확장(Extensibility)하기에 좋습니다. (예시 : OAuth)
• 동일한 토큰을 통해 여러 플랫폼 및 도메인의 CORS 문제에서 해방될 수 있습니다(네이버 로그인을 핸드폰에서도 하고, 폰으로도 하고)
• 웹 표준 기반 중 하나입니다(JWT는 웹 표준 RFC 7519에 등록되어 있습니다.)

Session 기반 vs Token 기반

서버(세션) 기반 인증 시스템

서버의 세션을 사용해 사용자 인증을 하는 방법으로 서버측(서버 램 or 데이터베이스)에서 사용자의 인증정보를 관리하는 것을 의미합니다.

그러다 보니, 클라이언트로부터 요청을 받으면 클라이언트의 상태를 계속에서 유지해놓고 사용한다.(Stateful) 이는 사용자가 증가함에 따라 성능의 문제를 일으킬 수 있으며 확장성이 어렵다는 단점을 가지고 있습니다.

 

토큰 기반 인증 시스템

이러한 단점을 극복하기 위해서 "토큰 기반 인증 시스템"이 생겼습니다.

인증받은 사용자에게 토큰을 발급하고, 로그인이 필요한 작업일 경우 헤더에 토큰을 함께 보내 인증받은 사용자인지 확인합니다.

이는 서버 기반 인증 시스템과 달리 상태를 유지하지 않으므로 Stateless 한 특징을 가지고 있습니다.

Token 인증 방식

1. 사용자가 아이디와 비밀번호로 로그인을 한다.
2. 서버 측에서 사용자(클라이언트)에게 유일한 토큰을 발급한다.
3. 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장해 두고, 서버에 요청을 할 때마다 해당 토큰을 서버 HTTP 요청 헤더에 포함시켜 전달한다.
4. 서버는 전달받은 토큰을 검증하고 요청에 응답한다. 토큰에는 요청한 사람의 정보가 담겨있기에 서버는 DB를 조회하지 않고 누가 요청하는지 알 수 있다.

Token 방식의 단점

1. 쿠키/세션과 다르게 토큰 자체의 데이터 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해질수 있다.
2. Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
3. 토큰을 탈취당하면 대처하기 어렵다. (따라서 사용 기간 제한을 설정하는 식으로 극복한다)

참조

쿠키와 세션 개념

🌐 JWT 토큰 인증 이란? (쿠키 vs 세션 vs 토큰)

[JWT] 토큰(Token) 기반 인증에 대한 소개 | VELOPERT.LOG