[Authentication] 쿠키, 세션, 토큰

개요

이전 포스팅에서 인증과 인가에 대한 개념적인 부분에 대해서 다뤘다. 
이번에는 서비스에서 인증/인가의 구현 방식인 쿠키, 세션, 토큰 방식에 대해서 알아보겠다.

쿠키 (Cookie)

쿠키의 개념

쿠키란 HTTP의 하이퍼 텍스트의 기록서의 일종으로 사용자가 특정 웹 사이트에 방문할 경우 사용자의 웹 브라우저를 통해서 인터넷 사용자의 컴퓨터나 다른 기기에 설치되어 있는 기록 정보 파일을 말한다.

 

위의 사전적인 내용을 조금 풀어보면, 특정 웹사이트에서 필요한 정보를 웹 사이트에 기록하는 도구라고 볼 수 있다. 일부 웹 사이트에 방문하면 쿠키 사용 설정을 동의하겠냐는 메시지나 쿠키 설정 옵션을 사용자에게 입력하라는 문구를 종종 봤을 거다. 이렇듯 쿠키는 특정 웹 페이지를 사용하는 사용자에 한해서 필요한 정보들을 가지고 있는다. 그리고 이러한 정보들을 기반으로 사용자를 구분하고 필요한 정보들을 제공해 주는 용도로 사용한다. 

 

이전 인증과 인가에서 HTTP 프로토콜은 비연결성(Connectionless), 무상태(Stateless) 한 성격을 지니고 있다고 말했다. 그렇기 때문에 로그인 페이지에서 로그인을 완료하고 다른 페이지로 넘어 갔을 때, 다시 재 로그인을 해서 해당 페이지에서 필요한 정보들을 받아와야 하는 경우가 생긴다. 이때 쿠키를 사용하면 로그인 유지와 같은 기능을 해결할 수 있다. 쿠키는 일반적으로 이후에 알아볼 세션과 함께 사용된다. 

 

쿠키의 주요 특징은 아래와 같다.

 

쿠키의 특징 

• 클라이언트에서 관리(세션과 반대)
• 사용자를 식별하고 상태를 유지하는 역할. 예를 들어, 사용자가 웹 사이트에 로그인한 후에는 쿠키를 사용하여 해당 사용자를 식별하고 로그인 상태를 유지할 수 있음 (유저 식별)
• 만료기간을 지정할 수 있음. (임시성)
• 크기 제한이 있다. 브라우저별로 최대 저장할 수 있는 크기가 다르다.
• 클라이언트에 저장되기 때문에 보안에 취약한 내용은 저장하지 않는게 좋다.

 

세션 (Session)

세션의 개념

서버-클라이언트 간의 상호 작용을 유지하는데 사용하는 부분으로 서버에서 가지고 있는 정보들을 말한다. 

 

세션은 클라이언트에게 고유한 세션 값(식별자)를 부여하고 사용자의 상태를 추적하며, 상호 작용을 유지하기 위해서 사용한다. 일반적인 클라이언트-서버 형태의 웹 서비스에서 클라이언트가 서버에 로그인 요청을 하면, 서버에서는 요청에 따른 고유한 세션 값을 부여하고 클라이언트의 고유값을 서버에서 관리한다. 이렇듯 세션은 주로 사용자 인증정보를 저장하거나 클라이언트의 상태를 유지하기 위해서 사용된다. 

 

세션의 주요 특징은 아래와 같다.

 

세션의 특징

• 서버에서 관리(쿠키와 반대) 
• 세션은 사용자를 식별하고 상태를 유지하는 데 사용된다. 클라이언트가 서버에 요청을 보낼 때 세션 ID를 함께 전송하고, 서버는 해당 세션 ID를 사용하여 해당 세션에 저장된 데이터에 액세스한다. (유저 식별)
• 쿠키와 동일하게 유효기간을 지정할 수 있다. 
• 세션은 서버에서 관리하기 때문에 클라이언트 측에서 관리하는 쿠키와 비교했을 때, 비교적 안전하다.
• 세션은 주로 사용자의 로그인 상태와 관련된 데이터를 저장하는 데 사용된다. 따라서 세션 데이터는 해당 사용자에게만 유효하며, 다른 사용자의 세션 데이터에 액세스할 수 없다.

 

쿠키-세션 인증 방식  

 

웹 서비스에서 쿠키-세션 방식을 사용하면 위와 같은 형식으로 사용자를 인증을 하고 사용자의 정보를 유지할 수 있다. 위 방식에 대해서 간략하게 요약하면 다음과 같다. 

 

1. 사용자가 서비스 이용을 위한 ID, Password 값을 담아서 서버에 로그인 요청
2. 서버에서 요청한 ID, Password 값을 바탕으로 사용자가 일치하는지 검증
3. 검증이 통과한 요청에 한해서, 세션 스토리지에서 사용자의 정보를 바탕으로 세션을 생성
4. 이때, 고유한 세션 Key(ID) 값을 발급 
5. 쿠키에 고유 세션 Key 값을 추가해서 클라이언트로 응답  

대표적으로 쿠키-세션방식을 사용하면 위와 같은 형식으로 서비스에서 인증 과정을 거친다. 쿠키-세션 인증을 통해서 HTTP 프로토콜의 비연결성과, 무상태에 대한 문제도 어느 정도 해결 할 수 있게 된다.

 

토큰 (Token)

 

토큰의 개념

토큰은 사용자의 인증 정보를 포함하는 문자열을 말한다. 서버로부터 발급되며, 일반적으로 사용자의 세션 상태를 유지하거나 클라이언트의 요청을 인증하는 데 사용된다. 클라이언트는 요청 시 해당 토큰을 함께 전송하여 인증을 수행한다.

 

위 개념에 나와있듯, 토큰은 인증 정보를 포함하는 문자열을 의미한다. 인증과정에서 토큰을 사용하면 기존 쿠키-세션 구조와 다르게 서버에서 사용자의 정보를 가지지 않기 때문에,  기존에 사용자 정보를 별도의 서버 스토리지에 저장하는 과정을 줄 일 수 있다. 

 

 

JWT 

 

토큰 기반의 인증에서 JWT 토큰은 대표적인 토큰 저장방식이다. JWT는 JSON Web Token의 약어로 특정 정보를 Base 64로 인코딩한 String 값에 저장하는 도구를 말한다. 예를 들어, 사용자의 기본적인 정보를 JSON 형식으로 저장했다가 인코딩한 정보를 기반으로 서버-클라이언트가 서로 통신을 하면서 인증을 수행한다.  JWT 토큰은 아래와 같은 특징을 갖는다.  

 

 

JWT 특징 

• Header, Payload, Signature 형식으로 구성되어 있으며 Base 64로 인코딩 되어있다.
• 서버에서 생성되고 클라이언트에 저장한다.
• 클라이언트 -> 서버로 요청을 보낼 때 JWT Token ID 값을 같이 보내면 현재 요청에 대해서 사용자가 누구인지 서버에서 알 수 있다.(JWT 토큰의 인증방식)
• 별도의 DB에 저장되지 않고 Signature 값을 이용하여 검증을 할 수 있다. 검증 시 DB를 찍고 올 필요가 없다. 
• 별도의 DB가 필요 없기에 수평적 확장(Horizontal Scaling)에 용이함하다. (확장성)

 

JWT 구조 

 

JWT의 구조는 Header, Payload, Signature로 이루어져 있다. 

Header

 

Header는 alg와 typ을 가지며, 각각 암호화할 해싱알고리즘과 토큰 타입을 정의한다. Header는 토큰의 유형과 서명 알고리즘을 지정한다. 

{
	"alg": "HS256",
	"typ": "JWT"
}

 

 

Payload

 

Payload는 실제로 전달하고자 하는 정보를 포함하고 클라이언트를 식별할 수 있는 고유 Key 값이나 권한정보, 토큰 만료 시간등을 포함한다. Payload에 담겨 있는 정보를 클레임(Claim)이라고 부르며  서버-클라이언트 간에 교환되는 정보를 의미한다. 

{
  "sub": "1234567890",
  "name": "bill_dev_wiki",
  "iat": 1516239022
}

 

 

 

Signature

 

Signature 은 Header와 Payload의 내용을 함께 해싱하여 생성된 값으로, 토큰이 위변조 되지 않았음을 검증하기 위한 계층이다. 주로 HMAC 또는 RSA와 같은 암호화 알고리즘을 사용하여 생성되며, 서버 측에서 비밀 키를 사용하여 생성된다. 이를 통해 토큰의 무결성을 보장하고 안전한 통신을 제공한다.

HMACSHA256(
	base64UrlEncode(header) + "." +
	base64UrlEncode(payload),
	my_cat_is_cute  -> 실제 secrete Key 
)

 

 

토큰의 인증방식

 

클라이언트 로그인 요청이 들어오면, 서버는 검증 후 클라이언트 고유 ID 등의 정보를 Payload에 추가한다. 암호화시킬 비밀키를 사용해 토큰을 발급한다. 클라이언트는 전달받은 토큰을 저장해 두고, 서버에 요청할 때마다 토큰을 요청 헤더 Authorization에 포함시켜 함께 전달한 이후, 서버는 토큰의 Signature를 비밀키로 복호화 후 위변조 여부 및 유효 기간 등을 확인 후, 유효한 경우 클라이언트로 값을 전달하는 형식으로 진행된다. 

 

토큰 기반 인증의 장단점 

 

장점

• 토큰의 Header & Payload를 가지고 Signature를 생성하기 때문에 데이터의 위변조를 막을 수 있다.
• 쿠키-세션 방식에서 사용자에 대한 정보를 별도의 서버의 스토리지에 저장을 했었는데 토큰은 별도의 저장소가 필요 없다.
• 서버에서 각 유저에 대한 인증정보가 별도로 필요 없기 때문에 확장성에 있어서 유리한 구조를 갖는다. 

 

단점

• 요청이 많아질수록 부하가 높아진다. 
• payload는 별도로 암호화되지 않기 때문에 중요 정보를 포함시킬 수 없다.
• 토큰의 만료기간이 정해져 있는 동안에 탈취당하면 대처가 어렵다.   

 

 

참고

JWT (JSON Web Token) 이해하기와 활용 방안 - Opennaru, Inc.

JWT.IO

 

서버 인증 방식(세션/쿠키, 토큰)