세션과 쿠키, JWT

세션과 쿠키는 왜 필요한가?

HTTP 프로토콜의 약점을 보완하기 위해 사용됩니다.

 

 * HTTP의 비연결성과 무상태

1) 비연결성
: HTTP는 인터넷상에서 불특정 다수의 통신 환경을 기반으로 설계되었습니다.
만약, 서버에서 다수의 클라이언트와 계속 연결을 유지한다면 많은 리소스가 발생합니다.
그래서 서버가 한 번 연결을 맺은 후,
클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어버리는 성질을 가지게 되는데
이를 비연결성이라고 부릅니다.
하지만 이러한 비연결성은 모든 요청에 대해 매번 새로운 연결을 시도하므로 연결/해제에 대한 오버헤드를 가집니다.

2) 무상태
서버가 클라이언트의 상태를 보존하지 않음으로 클라이언트의 상태를 알 수 없는 상태입니다.

 

이러한 무상태는 로그인이 필요없는 단순한 서비스 소개 화면 정도의 구현에는 유용합니다.

하지만 사용자가 로그인한 상태를 서버에 유지 시켜 줘야 하는 경우 무상태로는 설계를 할 수 없게 됩니다.

이를 위해 세션과 쿠키를 조합하여 상태를 유지합니다.

 

Cookie

클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일

• 사용자 인증이 유효한 시간을 명시할 수 있음
• 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지됨
• Response Header 에 Set-Cookie 속성을 사용해 클라이언트에 쿠키를 만들 수 있음

 

Cookie 구성요소

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

 

Cookie 동작방식

• 클라이언트가 페이지를 요청
• 서버에서 쿠키 생성
• HTTP 헤더에 쿠키를 포함시켜 응답
• 브라우저가 종료되어도 쿠키 만료 시간이 있다면 클라이언트에서 보관함
• 같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄
• 서버에서 쿠키를 읽어 이전 상태 변경할 필요가 있을 때 쿠키를 업데이트

 

Cookie 사용 예시

• 방문 사이트에서 "아이디,비번 저장하시겠습니까?"
• 쇼핑몰 장바구니 기능
• 자동로그인, 팝업에서 "오늘 더 이상 이 창 보지 않음" 체크

 

Session

브라우저와 웹 서버가 연결되어 브라우저가 종료될때까지의 시점

• 세션은 쿠키를 기반으로 하지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 서버 측에서 관리
• 서버는 클라이언트 구분을 위해 세션 ID를 부여하며, 웹 브라우저가 서버에 접속해 브라우저를 종료할 때가지 인증상태 유지
• 접속 시간에 제한을 두어 일정 시간 응답 없을 경우 유지되지 않게 설정 가능
• 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋음
• 하지만 사용자가 많아질수록 서버 메모리를 많이 차지함
• 즉, 동접자 수가 많은 경우 웹 서버에 과부하를 주게 됨

 

 

Session 동작 방식

1. 클라이언트가 브라우저를 통해 서버에 접속한다.

2. 서버는 세션id를 쿠키에 담아 되돌려준다.

3. 클라이언트는 세션id를 담은 쿠키인 세션 쿠키를 이후 요청부터 계속해서 전달한다.

이를 세션 기반 인증 방식이라고 하며, 간단하게 세션이라고 부른다.

 

Session 사용 예시

• 로그인 같이 보안상 중요한 작업 수행할 때 사용

 

JWT

JSON 객체를 사용해서 토큰 자체에 정보들을 저장하고 있는 Web Token

세션은 사용자 수 만큼 서버 메모리를 차지하기 때문에, 최근에는 이러한 토큰 기반 인증 방식을 사용한다.

 

 

JWT 구성

- Header

Signature 를 해싱하기 위한 알고리즘 정보들이 담겨져 있음

 

- Payload

서버와 클라이언트가 주고받는, 시스템에서 실제로 사용될 정보에 대한 내용을 담고 있습니다.

여기에 담는 정보의 "한 조각" 을 클레임이라고 부릅니다. 이 클레임은 토큰에 여러개가 들어갈 수 있습니다.

클레임은 name/value 한 쌍으로 이뤄져 있습니다.

 

ex. 클레임 토큰 예시

{
    "id" : "tjdwns",
    "role" : "user",
    "email" : "tjdwns4537@email.com"
}

 

- Signature

토큰의 유효성 검증을 위한 문자열로, 이 문자열을 통해 서버에서는

이 토큰이 유효한 토큰인지 아닌지를 검증할 수 있음

 

 

JWT 장점

- 중앙의 인증서버, 데이터 스토어에 대한 의존성 없음, 시스템 수평적 확장에 유리

- Base64 URL Safe Encoding -> URL, Cookie, Header 모두 사용 가능

 

 

JWT 단점

- PayLoad 정보가 많아지면 네트워크 사용량 증가, 데이터 설계 고려 필요

- 토큰이 클라이언트에 저장되기 때문에, 서버에선 클라이언트의 토큰을 조작할 수 없게 됩니다.

 

 

JWT  사용 과정

1. 유저가 로그인

2. 유저의 정보를 기반으로 토큰을 발급해 유저에게 전달

3. 유저가 서버에 요청을 할때마다 JWT를 포함하여 전달

4. 서버가 클라이언트에게서 요청을 받을때마다, 토큰이 인증가능한지 검증

5. 유저가 요청한 작업에 권한이 있는지 확인하여 작업 처리

 

 

JWT 를 왜 사용하는가?

쉽게 말해 JWT는 일종의 확인서이다.

우리가 웹사이트에 로그인을 하여 Authentication이 이뤄지면, 서버는 사인된 JWT를 우리에게 제공한다.

그러면 앞으로 요청할 때 마다 JWT를 서버에게 같이 보여주면서 권한을 확인받는 것이다.

서버는 JWT만 확인해 Authentication하기 때문에 세션DB에 저장할 필요가 없다.

즉, JWT를 서버에 발급할 때, 검증할 때만 확인서를 다루기 때문에 서버 자원을 효과적으로 절감할 수 있다.