[면접 준비 - Network]쿠키, 세션, 토큰, 그리고

목차

 

Cookie

 

쿠키와 세션은 HTTP의 특징인 비연결성과 무상태성을 보완하기 위한 도구이다.

 

• Connectionless - 클라이언트가 요청을 한 후 응답을 받으면 서버가 그 연결을 끊어 버리는 특성
• Stateless - 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며, 상태 정보를 유지하지 않는 특성

쉽게 말하면 페이지 이동마다 로그인을 새로 해야 한다는 의미이다.

 

쿠키는 웹 서버에 의해 생성되는, 바로 삭제되지는 않는 데이터 패킷으로, 클라이언트의 기기에 저장된다.

 

서버가 이 쿠키에 인증 정보를 담아 발행하면 클라이언트가 요청과 함께 쿠키를 제출하는 방식으로 연결이 유지된다.

 

클라이언트의 기기에 저장된다는 특징 때문에 서버의 부담이 줄어든다는 단점과 보안에 취약하다는 단점이 공존한다.

 

또한 일종의 기록파일이기 때문에 인증정보 외에 사용자의 활동을 기록할 수도 있으며, 수시로 갱신되는 특징이 있다.

 

추가로 서버에서 클라이언트로 처음 쿠키를 전송할 땐 헤더의 'Set-Cookie' 속성에 담아 보내며

 

이후 클라이언트는 'Cookie'헤더에 쿠키를 담아 전송한다.

 

마지막으로 쿠키에는 아래와 같은 옵션을 설정할 수 있다.

 

• Domain - 쿠키의 옵션과 서버의 도메인이 일치하는 경우에만 쿠키 전송 가능
• Path - 도메인 이후의 세부 경로를 모두 만족하면 추가 경로가 있어도 쿠키 전송 가능
• MaxAge/Expire - 쿠키의 수명을 초단위/날짜와 시간 단위로 결정한다.
  
  
  • 영속성 쿠키 - 수명이 지정된 쿠키
  • 세션 쿠키 - 수명이 지정되지 않아 브라우저 종료와 함께 삭제되는 쿠키
• Secure - 쿠키 전송 시 사용하는 프로토콜 설정. 'true'일 경우 HTTPS만 허용한다.
• HttpOnly - JS의 쿠키 접근 여부 결정. 'true'인 경우 접근이 불가능하며, 'false'인 경우 XSS 공격에 취약해진다.
  
  
  • XSS - 크로스 사이트 스크립팅. HTTP 통신 시 웹에 스크립트 코드를 삽입해 특정 행동 수행 또는 정보 탈취
• Samesite - CORS요청을 받은 경우의 쿠키 전송 여부
  
  
  • Lax - 'GET' 메서드에 대해서만 전송 가능
  • Strict - 전송 불가
  • None - 항상 전송 가능

 

Session

 

세션은 쿠키를 기반으로 하는, 기한이 정해진 양방향 연결, 또는 그 기한 자체를 가리킨다.

 

여기서 기한이란 일반적으로 브라우저의 작동 시간을 말하며, 세션은 브라우저 종료와 함께 삭제된다.

 

쿠키와는 다르게 데이터를 서버에 저장하기 때문에 보안이 우수하다는 장점과, 서버 리소스에 무리가 간다는 단점이 공존한다.

 

구체적으로는 클라이언트의 최초 요청과 함께 서버는 세션을 구분하기 위한 ID를 부여해 생성하며,

 

이 인증 상태를 (특별한 옵션이 없다면) 브라우저 종료 시점까지 유지한다.

 

조금 더 상세한 서버 인증 과정은 아래와 같다.

 

1. 정확한 아이디와 비밀번호를 입력한 사용자를 위해 세션 스토어에서 세션 및 세션 ID 생성 및 반환
   
   
   • 사용자가 정확한 정보를 입력해 인증에 성공한 상태를 세션이라고 부름
   • 서버는 인증에 성공한 사용자를 기억하기 위해 세션 스토어(일종의 DB)에 저장
   • 세션이 생성되면 세션을 구분할 수 있는 세션 ID 생성 및 클라이언트에게 전달
   • 클라이언트는 인증 성공을 증명할 수단으로 쿠키에 세션 ID를 저장
2. 세션 ID를 요청 헤더에 담아 전송한 사용자를 위해 새로운 요청 처리 및 응답
   
   
   • 클라이언트는 세션이 유지되는 동안 요청 헤더에 세션 ID를 자동으로 추가
   • 서버는 세션 ID 체크 후 유효하다면 요청 처리 및 응답

이때 세션 ID가 담긴 쿠키는 상대적으로 보안에 취약하기 때문에, 공공장소에서는 반드시 로그아웃을 해야 한다.

 

Cookie vs. Session

 

	쿠키	세션
저장 위치	클라이언트 로컬	서버 자원 사용
보안	취약(연결성 > 안정성)	우수(안정성 > 연결성)
속도	빠름	중간
수명	브라우저 종료시에도 남음	브라우저 종료와 함께 삭제
사용 예시	사이트 아이디/비밀번호 저장 쇼핑몰 장바구니	로그인 등 보안상 중요한 작업
공통점	CSR 방식과 어울리지 않아 SPA를 이용할 수 없음 → UX 및 서버 부하 차원에서 불리

 

추가

 

쿠키와 세션이 CSR과 어울리지 않는 이유는 CSR이 말 그대로 서버가 아닌 클라이언트 측에서 렌더링을 하기 때문이다.

따라서 서버에서 생성해 클라이언트와 서버 사이의 상태를 유지하는 쿠키와 세션은 CSR과 궁합이 좋지 않은 것이다.

조금 더 자세히 말하면 CSR 방식에서는 클라이언트가 생성된 HTML에서 JS 등을 이용해 데이터를 가져오기 때문에 HTTP의 특성상

클라이언트-서버 사이의 상태 정보가 유실되어 상태를 유지할 수가 없게 된다.

 

따라서 CSR방식에서는 쿠키나 세션이 아닌 토큰, 혹은 JWT등의 인증방식을 사용하는 것이 일반적이다.

 

Token

 

토큰은 한 마디로 말하자면 일종의 임시 출입증이며,

 

올바른 크리덴셜(아이디, 비밀번호, 혹은 OAuth2)을 제출하고 서버에서 발급받는다.

 

기한이 정해져 있으며, 자격증명을 하는 동시에 접근 권한을 제한해 특정 리소스로의 접근만을 허용한다.

 

토큰 기반 인증 방식은 세션 기반 인증 방식과 절차상 비슷한 흐름을 갖지만,

 

결정적인 차이점으로 토큰 기반 인증 방식엔 세션 저장소가 없다. 즉, 사용자 정보를 서버에서 관리하지 않는다.

 

올바른 요청이 들어와 인증이 끝난 경우 서버는 토큰을 생성, 서명 후 쿠키 혹은 헤더에 담아 반환하며

 

사용자는 이후의 요청에 토큰을 담아 보내게 된다.

 

이 토큰은 만료되기 전까지는 무효화시킬 수 없으며, 보안을 위해 만료시간을 짧게 두고 Refresh Token을 발급해 사용한다.

 

토큰 방식의 나머지 특징은 아래와 같다.

 

• 토큰에 인증된 사용자 정보가 담겨 있어 상대적으로 네트워크 부하가 크다.
• 토큰을 서버 측에서 관리하지 않으므로 상대적으로 보안이 취약하다.
• 사용자가 많아져도 서버에 부담이 상대적으로 덜하다.
• 서버의 확장성이 뛰어나고, 세션 불일치 같은 문제가 발생하지 않는다.
• 토큰에 포함되는 정보는 암호화가 되지 않기 때문에 민감한 정보를 담을 수 없다.
• CSR(Client Side Rendering)에 적합한 방식이다.

 

Session vs. Token

 

	세션 기반 인증	토큰 기반 인증
네트워크 부하	적음	큼
보안	강함	취약
서버 부담	큼	적음
서버 확장성	작음	큼
렌더링 방식	SSR	CSR

 

JWT

 

JWT는 말 그대로 JSON으로 만들어진 웹 토큰을 말한다.

 

조금 구체적으로는 토큰 기반 인증 방식의 취약한 보안을 조금이라도 보완하면서도

 

간결하게 통신하기 위한 표준 인증방식이라고 할 수도 있다.

 

헤더, 페이로드, 시그니처로 나뉘어진 구조를 가지고 있으며

 

일반 토큰과 비슷하게 Access Token, Refresh Token으로 나뉜다.

 

일반적으로 보안을 위해 Access Token의 만료 시간을 짧게 설정하고 Refresh Token을 사용하지만,

 

그러나 간혹 보안이 매우 중요한 앱에서는 Refresh Token을 사용하지 않고

 

만료 시간마다 새로 인증을 요구하기도 한다.

 

마지막으로 토큰과 묶어서 JWT의 장단점을 정리하자.

 

Pros

 

• 상태를 유지하지 않으며(Stateless), 확장성이 좋은(Scalable) 앱을 구현하기 편하다.
  
  
  • 서버는 토큰의 검증여부만 판단한다.
  • 클라이언트의 정보가 서버에 저장되지 않기 때문에 부하가 덜 걸린다.
  • 여러 대의 서버를 이용한 서비스라도 하나의 토큰으로 인증이 가능하다.
• 클라이언트가 요청마다 인증 정보를 전송할 필요가 없다.
  
  
  • 처음 한 번의 인증 후 토큰을 만료 전까지 사용할 수 있다.
• 인증 시스템의 분리가 편리하다.
  
  
  • 자격 증명 정보를 직접 관리하지 않기 때문에 Google 등 다른 플랫폼의 자격 증명 정보로 인증이 가능하다.
  • 토큰 생성용 서버를 따로 만들거나 다른 회사에 토큰 관련 작업을 맡기기 쉽다.
• 권한 부여가 편리하다.
  
  
  • 토큰의 페이로드 안에 권한 정보를 포함할 수 있다.

 

Cons

 

• 페이로드의 디코딩(복호화)이 간단하다.
  
  
  • 페이로드는 base64로 인코딩 되기 때문에 토큰으로부터 데이터를 확인하기가 용이하다.
• 토큰의 정보가 많아지면(길이가 길어지면) 네트워크에 부하가 간다.
• 토큰은 자동으로 삭제되지 않으므로 반드시 적절한 만료 시간을 설정해야 한다.

 

OAuth 2.0

 

OAuth(Open Authorization)는 사용자의 비밀번호 없이도 접근 권한을 받을 수 있는 개방형 표준이다.

 

구체적으로는 사용자가 사용하는 앱(여기서는 클라이언트라 부른다)이 보안을 위해 인증을 다른 업체에게 맡겨버리고

 

서버로부터 접근 권한만 획득하는 방식, 혹은 그 방식에 대한 표준이 OAuth라고 생각하면 된다.

 

두 번이나 반복해서 나왔지만 굳이 강조하자면, OAuth는 인증이 아닌 권한 부여에 대한 표준이다.

 

흔히 소셜 로그인이라고 불리는 방식이며, 사용자 편의성에 더해 사용자 정보를 저장하지 않아도 돼 보안이 향상된다.

 

OAuth 2.0에서 사용하는 용어를 요약하면 아래와 같다.

 

• Resource Owner - 사용자. 클라이언트 인증 후 권한 획득 자격(Authorization Grant)을 클라이언트에 위임하는 역할.
• Client - 보호된 리소스에 접근하는 애플리케이션, 즉 서버의 클라이언트. 사용자가 사용하는 앱이라 생각하면 된다.
• Third-Party Application - 사용자 인증 과정(Authentication)을 위임받은 기업 및 애플리케이션.
• Authorization Server - 인증 후 클라이언트에게 Access Token의 형태로 권한을 부여하는 서버.
• Authorization Grant - 권한 인증 방식. 크게 네 가지 방식으로 나뉜다.
• Scope - Access Token을 이용해 액세스 할 수 있는 리소스의 범위.
• Resource Server - 리소스(데이터, 서비스)를 제공하는 서버.

또한 OAuth를 사용하는 애플리케이션의 목적은 크게 두 유형으로 나뉘는데,

 

• Third-Party Application의 API를 직접적으로 사용
• 위 이유에 더해 추가적인 인증 서비스 제공

이 그것이다.