요약

• HTTP를 이용한 통신에서 로그인 상태 같은 Stateful 상태를 유지하기 위해서 Session과 Cookie 또는 Token을 이용한 방법을 사용 합니다.
• Session을 이용할 경우, 인증이 완료 되면 사용자의 Session 정보를 서버에 저장하고 해당 Session 정보를 식별할 수 있는 session_id를 클라이언트에게 전달합니다. 이 때, 클라이언트와 서버는 cookie를 이용하여 session_id를 주고받습니다.
• Token은 제한된 리소스에 대해 일정 기간 동안 접급 할 수 있는 권한을 가지고 있는, 일종의 통행권 입니다.
• Token은 Session과 달리 서버에 token 정보를 저장하지 않습니다.
• Token을 이용하면 서버의 상태를 Stateless 하게 유지 할 수 있어 서버 확장에 유리합니다.
• Token을 이용하여 다양한 기기에서 서비스가 호환 되도록 운영할 수 있습니다.

1. Introduction

HTTP의 특징

• 요청과 응답으로 통신
• Stateless
  과거의 통신(요청/응답)에 대한 내용을 전혀 알지 못 함. (=독립적)
  매 통신마다 필요한 모든 정보를 담아서 요청을 보내야 한다.
• 여러번의 요청/응답 중 연속된 데이터 처리가 필요한 경우
  예: 로그인 후 상품 구매/개인정보 수정
  Stateless의 특징에 따라 매번 로그인을 위한 인증정보를 같이 보내줘야 함
• 일부 정보에 대해서 Stateful 상태를 유지할 필요.
  👉 Session, Cookie, Token 기술.

2. Session based Authentication

2-1. Session and Cookie

Session

• 정의: 동일한 클라이언트(사용자)가 브라우저를 통해 웹 서버에 접속한 시점으로부터 브라우저를 종료하여 연결을 끝내는 시점 동안에 들어오는 일련의 Request를 하나의 상태로 보고, 그 상태를 일정하게 유지하여 클라이언트와 웹 서버가 논리적으로 연결된 상태
• Session ID: 서버가 클라이언트에게 부여한 세션 구분용 ID.
  서버는 세션 정보를 저장.
• 서버: 클라이언트 Request(+Session ID)를 보내, 클라이언트의 상태를 확인

Cookie

• 정의: 클라이언트의 컴퓨터에 저장되는 데이터 파일.
• 구성: 이름, 값, 만료 날짜/시간(저장기간), 경로 정보
• 특징: 하나의 도메인 당 쿠키 20개, 쿠키 1개 당 4Kbyte이하.
• 서버: HTTP Response Header에 Set-Cookie 속성을 이용하여 클라이언트에 Cookie를 제공하여 저장하게 함,
• 클라이언트: HTTP Request에 저장된 Cookie를 함께 전달, 이전의 통신에서 사용된 정보들을 파악.
  예) 장바구니 기능
  • 과거: 로그인 필수,
  • 최근: Cookie를 이용해 로그인 없이 가능
• Cookie를 통해 사용자별로 다른 정보를 표시, 사용자의 행동과 패턴을 분석

2-2. Session과 Cookie를 이용한 인증 Flow

2-3. Session 기반 인증의 특징

장점

• Session ID 자체에는 유의미한 개인정보 없음.
• 서버에서 정보를 관리하므로 데이터의 손상 우려에 대해 상대적으로 안전
• 서버에서 상태를 유지하므로 사용자의 로그인 여부 확인이 쉽고, 경우에 따라 강제 로그아웃 등의 제재.

단점

• 서버에서 모든 사용자의 상태를 관리: 사용자 수에 비례하여 서버 부하 증가
• 사용자 수 증가로 서버의 Scale Out을 해야할 시, Session 관리 어려움
• 모바일 기기, 브라우저에서 공동 사용 시, 중복 로그인 처리가 되지 않는 문제 등 관리포인트 증가

3. Token based Authentication

3-1. Token

제한된 리소스에 대해 일정 기간 동안 접급 할 수 있는 권한을 캡슐화 한 것

웹에서의 Token: 해당 서비스를 이용할 수 있는 권리

• 의미를 알 수 없는 임의의 문자열 형태로 사용자에게 발급
• 제한된 리소스에 대한 접근 권한을 캡슐화
• 접근 할 수 있는 리소스의 범위와 접근 가능한 기간을 통제

참고
일상에서 의미: 버스를 탈 권리, 도는 자동판매기에서 상품을 구매할 권리
by the same token : 같은 이유로, 마찬가지로

3-2. Token을 이용한 인증 Flow

리프레시 토큰, 액세스 토큰

3-3. Token 기반 인증의 특징

장점

• Token을 사용자 측에서 저장: 서버의 메모리, DB의 부담 없음
• 사용자의 상태 정보를 서버에서 관리하지 않아 서버의 Scale Out에 용이
• 모바일, 브라우저의 멀티 환경 사용이 용이
• Token의 만료 시간을 짧게 설정하여 안정성 향상
• CORS 방식의 사용 용이

단점

• 서버에서 사용자의 상태를 저장하고 있지 않아 사용자의 로그인 여부 확인, 경우에 따른 강제 로그아웃 등의 제재가 어려움
• 사용자가 토큰을 임의 수정, 구조 변경 시 서버에서 확인 불가
• HTTP request 전송 데이터의 크기 증가: Payload 부분에 사용자 식별을 위한 여러 정보들이 포함 되어 있어 Session Id 길이보다 길어짐
• XSS 공격에 취약: Payload에 민감한 정보 포함 시 위험

scale out : 같은 성능의 서버의 수를 늘림
scale up : 서버 1 대의 성능을 높임

XSS 공격
웹사이트 관리자가 아닌 이가 웹페이지에 악성 스크립트를 삽입할 수 있는 취약점

• http 헤더 분석하면 X가 많이 보이는데 cross 의미
• cross-site scripting
  👉 링크

4. Token based Authentication의 이점

1. Stateless

• 상태 정보를 사용자 측에서 관리하므로 서버 상태를 Stateless하게 유지
• 서버측에서는 사용자로부터 받은 Request만을 가지고 작업 수행 가능

2. Scalability

• 서버의 상태를 Stateless 하게 유지 한다는 것은 사용자와 서버 사이에 관계가 없다는 의미
• 서비스를 운영 중인 어떤 서버로든지 Request를 보낼 수 있음
  : 로그인 상태를 유지하기 위해 최초 로그인 시에 Request한 서버로 계속 Session ID를 보내주는 관계가 없음
  👉서버의 확장에 유리

3. Security

• 클라이언트가 서버에 요청 시 Cookie를 전달하지 않아, CSRF 공격 방지에 도움
• 토큰 환경 취약점에 대비해야 한다.

CSRF 공격
CSRF(Cross-Site Request Forgery), 악성 웹 사이트 공격 유형
서로다른 백엔드와 프론트엔드 서버 간 주고 받는 관계에서 중간에 견제, 발생
👉 링크

4. Extensibility

• 토큰을 통해 권한의 범위를 지정한다
• KaKao, Facebook, Google 등 소셜 계정으로 다른 웹서비스에서도 로그인 가능

[Keyword] oauth 알아보자~
👉 링크

5. Multiple Devices and Domains

• 서버 기반 인증 시스템의 문제점 중 하나인 CORS 해결
• 애플리케이션과 서비스의 규모 확장 시, 여러 기기들 호환시키고 더 많은 종류의 서비스 제공
• 어떤 기기나 도메인에서도 토큰의 유효성 검사 후에 요청을 처리