쿠키와 세션

쿠키와 세션은 웹사이트 상에서 사용자의 상태를 추적하고 관리하기 위해 사용되는 기술.
HTTP 프로토콜은 비연결성과 무상태의 특징을 갖기 떄문에 클라이언트의 연속적인 상태를 유지하게 해준다.

쿠키(Cookie)

쿠키는 클라이언트 측, 즉 사용자의 웹 브라우저에 저장되는 작은 데이터 파일이다.
웹 서버는 HTTP 응답을 통해 쿠키를 사용자의 컴퓨터에 전송하고, 이후 사용자가 동일한 요청을 보낼 떄마다 쿠키를 자동으로 해당 요청과 함께 서버로 보낸다. 이를통해 서버는 사용자를 식별하고 이전 상태를 기억하게 된다.

특징

• 데이터가 사용자의 PC에 저장됨.
• 각 쿠키는 도메인별로 저장되며, 각 쿠키의 크기과 횟수는 제한이 있다.
• 만료 날짜/시간이 지정되어 있어, 그 시점이 지나면 쿠키는 자동으로 삭제된다.

쿠키의 동작 순서.

1. 클라이언트가 페이지를 요청한다.
2. 웹 서버는 쿠키를 생성한다.
3. 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려준다.
4. 넘겨받은 쿠키는 클라이언트가 가지고 있다(로컬 PC) 다시 서버에 요청할 때 요청과 함께 쿠키를 전송한다.
5. 동일 사이트 재방문 시 클라이언트 PC애 해당 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송한다.

세션(Session)

세션은 서버측에서 관리된다. 사용자가 웹 사이트에 접속하여 작업을 시작할 때 서버는 세션ID를 생성하여 사용자에게 전송하고, 이 세션ID를 통해 서버는 사용자의 상태를 유지한다. 세션ID는 보통 쿠키를 사용하여 클라이언트에 저장되지만, 실제 데이터는 서버에 저장된다.

특징

• 데이터는 서버에 저장된다.
• 세션은 서버 자원을 활용하기 떄문에 동시에 많은 세션을 관리하는 것은 서버에 부담을 줄 수 있다.
• 세션은 보안 측면에서 쿠키보다 우수할 수 있다. 데이터가 클라이언트에 직접적으로 저장되지 않기 때문.
• 사용자가 로그아웃하거나 일정 시간동안 활동이 없을 경우 세션은 종료될 수 있다.

세션의 동작 순서

1. 클라이언트가 페이지를 요청한다.
2. 서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하여, 클라이언트가 해당 session-id를 보냈는지 확인한다.
3. session-id가 존재하지 않는다면 서버는 session-id를 생성해 클라이언트에 돌려준다.
4. 서버에서 클라이언트로 돌려준 session-id를 쿠키를 사용해 서버에 저장한다
5. 클라이언트는 재접속시, 이 쿠키를 이용해 session-id값을 서버에 전달한다.

토큰(Token)

사용자의 인증을 관리하는 매커니즘 중 하나.

세션 같은 경우 다수 동시 접속 시 메모리 부족으로 인해 메모리가 꺼지는 문제가 생길 수 있다.
이럴 경우, 모든 사용자의 로그인이 튕길 수 있다.

이를 해결하기 위해 HDD나 DB를 이용하게 되면 속도가 느리게 된다.

해결책으로 레디스와 같은 메모리형 DB 서버를 사용하지만, 근본적인 문제를 해결해주지 못한다.

그래서 이러한 부담을 없이 고안된 것이 바로 토큰 방식이다.

토큰 인가 방식

토큰 인가 방식은 사용자가 로그인 시 이를 검증하기 위해 사용자에게 토큰(Token)을 발급해준다.
이 토큰은 서버가 아닌 클라이언트에서 관리하게 되며 사용자가 요청을 보낼 때마다 이 토큰을 보내어 사용자 상태를 유지한다.

토큰 방식 중 많이 사용되는 방식이 JWT이다.

JWT(Json Web Token)

Json으로 된 웹 토큰이라는 뜻.

주로 사용자 인증과 정보 교환에 사용되며, 웹 서버와 클라이언트 간의 HTTP 헤더를 통해 전송된다.

JWT는 세 부분으로 구성된다.

1. 헤더(Header)

해더는 두 가지 정보를 포함한다.
토큰 타입 typ 를 나타내는 JWT 값과, 서명을 해싱하기 위해 사용된 알고리즘 alg를 명시한다.

예를 들어, HMAC SHA-256 알고리즘을 사용하는 경우 다음과 같은 JSON 객체로 표현.

{
  "alg" : "HS256"
  "type" : "JWT" 
}

2. 페이로드(Payload)

페이로드는 클레임이라고 하는 일련의 정보를 담고 있음.
클레임은 세가지 유형으로 나뉨 등록된, 공개, 비공개 클레임.

클레임의 데이터는 토큰을 누가 누구에게 발급했는지, 유효시간, 서비스가 사용자에게 공개하기 원하는 내용(닉네임, 서비스 상 레벨, 관리자 여부) 등의 정보들.

예를 들어, 사용자 정보와 만료 시간을 포함하는 페이로드는

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

3. 서명

서명은 토큰의 무결성과 인증을 보장하기 위해 생성된다.

헤더의 인코딩된 문자열과 페이로드의 인코딩된 문자열을 합치고, 제공된 비밀키를 통해 alg 의 알고리즘으로 해싱한다.

예를들어, HS256 알고리즘을 사용할 경우

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

JWT 최종 형태는 위 세 부분을 점(.)으로 연결한 문자열이다

Base64Url(header).Base64Url(payload).Base64Url(signature)

정리

서버는 사용자 요청과 함께 실어보낸 토큰의 1번 헤더와 2번 페이로드와 서버의 비밀키를 alg 알고리즘에 넣고 돌린다.
그것이 3번 서명 값과 일치하다면 인가하게 된다.

이렇게 JWT방식은 세션과 다르게 사용자들의 상태를 저장할 필요 없이 요청이 들어올 때마다 서버의 비밀키로 확인만 해주면 앞선 세션의 문제를 해결해줄 수 있다.

그러나 JWT의 결점은 상태를 저장하지 않아 해당 사용자의 정보를 서버에서 기록하거나 추적하지 않는 것이다.

예를들어 한 기기에서만 로그인 가능한 서비스를 할 때 다른 기기로 로그인 한 사용자가 있다면. 기존 기기에 주었던 토큰을 다시 반환할 수 없고 토큰 기록과 추적이 불가능하다.

또한 토큰이 탈취당한 경우 해당 토큰을 무효화 할 수 없다.

그럼 JWT는 못 쓰는건가?

이를 보완한 방법이 access & refresh 토큰 방식.
토큰을 두 개 주는 방식으로 몇 분이하 짧은 access 토큰과 2주 정도로 긴 refresh 토큰으로 구성된다.