쿠키, 세션, 토큰, Hybrid 토큰 인증 방식의 차이

인증의 필요성

HTTP 통신은 요청과 응답이 종료되면 연결을 끊는 Connectionless 특성과 연결이 끊어지면 어떠한 상태도 유지하지 않는 Stateless한 처리 방식이다.

따라서, 로그인을 유지하기 위해서 쿠키, 세션, 토큰을 사용한다.

• Connectionless 프로토콜
  • 클라이언트가 서버에 요청하고 응답을 받으면 연결을 끊는 처리 방식
• Stateless 프로토콜
  • 클라이언트의 상태 정보를 가지지 않는 서버 처리 방식이다.

 

 

1. 쿠키 🍪

쿠키는 Key-Value 형식의 문자열로 사용자에게 맡겨도 되는 공개 가능한 정보를 사용자 브라우저에 저장시킨다.

쿠키 동작 방식

• 서버는 클라이언트의 로그인 요청에 대해 응답할 때, 클라이언트를 식별하는 작은 정보를 Response Header의 set-cookie에 담는다.
• 클라이언트 측 브라우저는 해당 쿠키를 쿠키 저장소에 저장하고 다른 요청을 할 때마다 저장된 쿠키를 Request Header의 cookie에 담는다.
• 서버는 전달받은 쿠키를 통해 클라이언트를 식별할 수 있다.

 

쿠키는 브라우저 내에 저장되기 때문에 document.cookie를 통해 쉽게 쿠키에 접근할 수 있고 이를 이용해 쿠키의 데이터를 열어보거나 악용할 수 있기 때문에 보안에 취약하다. 따라서 절대 개인적인 비밀 정보들을 쿠키에 저장하면 안된다.

따라서 보안에 민감한 사이트에서는 만료기한을 짧게 가져가는게 좋다.

 

Secure 쿠키

Secure 쿠키는 HTTPS 프로토콜 상에서 암호화된 요청일 때만 전송되는 쿠키이다.

 

HttpOnly 쿠키

HttpOnly 쿠키는 XSS 공격을 방지하기 위해 document.cookie와 같은 JS로 쿠키를 조회하는 것을 막아준다.
해당 방식은 브라우저에서 쿠키를 조회할 수 없고, 서버로 요청 보낼 때 알아서 같이 전송된다.

 

Secure 쿠키와 HttpOnly 쿠키를 적용하더라도 쿠키는 본질적으로 안전하지 않고 보안을 실질적으로 제공하지는 않기 때문에 민감한 정보를 저장해서는 안되는건 똑같다.

 

 

2. 세션 🔗

세션은 사용자가 로그인을 한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점까지 상태를 유지하는 기술이다. (Stateful)

 

세션은 민감한 정보가 들어갈 수 있는 쿠키 대신에 사용자의 식별자인 Session ID를 저장한다.
서버에서도 인증 정보와 더불어 해당 Session ID에 해당하는 사용자 정보를 별도로 저장하여 관리한다.
서버의 메모리 또는 로컬 파일, 데이터베이스에 저장할 수 있다.

 

브라우저를 종료하거나, 서버에서 문제가 생겼을 때 세션을 삭제하여 사용하지 못하도록 할 수 있으므로 쿠키보다 보안성이 좋다.
또한, 저장 데이터에 제한이 없다라는 특징이 있다.

서버에서 세션을 따로 관리해야 하기 때문에 서버의 부하가 늘어날 수 있다는 단점이 있다.

세션 동작 방식

• 서버는 클라이언트의 로그인 요청에 대해 응답할 때, 클라이언트를 식별할 수 있는 개별 Session ID를 부여한다.
• Session ID를 담은 세션 쿠키와 함께 Response를 진행한다.
• 클라이언트 측 브라우저는 해당 쿠키를 쿠키 저장소에 저장하고 다른 요청을 할 때마다 저장된 세션 쿠키를 Request Header에 담아서 보낸다.
• 서버는 전달받은 쿠키를 통해 클라이언트를 식별할 수 있다.

세션 ID에는 특별한 값이 들어있지 않고, 서버에서 저장하고 있는 세션 ID의 value에 식별할 수 잇는 값이 들어있으므로 세션 ID가 탈취당하더라도 쿠키보다는 안전하다.

하지만 세션 ID를 탈취당하면 다른 사람이 마음대로 사용할 수 있지만 해당 부분은 서버에서 IP를 특정하는 방법으로 해결할 수 있다.

 

쿠키와 세션 비교

 

 

3. 토큰

기존 세션기반 인증은 서버가 파일이나 데이터베이스에 세션정보를 가지고 있어야 하고 이를 조회하는 과정이 필요하기 때문에 많은 오버헤드가 발생한다. 하지만 토큰은 세션과는 달리 서버가 아닌 클라이언트에 저장되어 있기 때문에 메모리나 스토리지 등을 통해 세션을 관리했던 서버의 부담을 덜 수 있다.

하지만, 실질적으로 로그아웃 처리 등을 하기 위해서는 Hybrid 방식으로 데이터베이스를 함께 사용하는게 일반적이다.

 

토큰 동작 방식

• 서버는 클라이언트의 로그인 요청에 대해 응답할 때, 클라이언트에게 토큰을 부여한다.
• 클라이언트 측에서 토큰을 저장해 두고, 요청을 보낼 때마다 Request Header에 추가하여 요청하다.
• 서버는 클라이언트로부터 받은 토큰이 서버에서 제공한 토큰인지 검증한다.

 

토큰의 대표적인 방식에는 JWT가 있다. JWT는 단순 웹 토큰(SWP) 및 SAML(Security Assertions Markup Language) 토큰에 비해 여러 이점이 있다.

• More Compact : JSON으로 인코딩 하기 때문에, XML로 인코딩하는 SAML 토큰보다 작다.
• More Secure: JWT는 공개키와 개인키를 나누어 서명이 가능하다. HMAC 암호 알고리즘을 이용하여 암호화된 서명이 가능하다.
• More Common: JSON의 object 방식은 일반적으로 많이 사용하므로 접근성이 좋다.
• Easier to process: JWT는 인터넷 규모로 사용되기 때문에, 모바일에서 처리할 때도 쉽게 사용 가능하다.

 

 

 

JWT 토큰의 구조

토큰은 Header, Payload, Signature 총 3파트로 구성되어 있다.

 

Header - JWT

JWT에서 사용할 타입과 해시 알고리즘의 종류가 들어있다. 즉, 어떻게 검증하는가에 대한 내용을 담고 있다.

alg는 서명 시 사용하는 해시 알고리즘이고, typ는 서명 시 사용하는 키(public/private key)를 식별하는 값이다.

 

 

Payload - JWT

서버에서 첨부된 사용자 권한 정보와 데이터가 담겨있다. Payload에 있는 속성들을 Claim Set이라고도 부른다.

Claim Set은 JWT에 대한 내용(토큰 생성자의 정보, 생성일시 등)이나 클라이언트와 서버 간 주고받기로 한 데이터로 구성된다.

 

Signature - JWT

Header와 Payload를 Base64 URL-safe Encode를 한 이후 해당 문자열을 전자서명한 값이다.
Header에 명시된 해시 알고리즘과 비밀키를 이용해 전자서명을 생성한다. 그 후 마지막으로 한번 더 Base64 URL-safe Encode 한다.

 

JWT 토큰 인증 과정

1. 클라이언트가 서버로 로그인 요청한다.
2. 아이디 패스워드 일치 시 서버는 Jwt Access Token과 Refresh Token을 발급하여 클라이언트에게 전달한다.
3. 클라이언트는 액세스 토큰을 사용하여 다른 요청을 보내고, 서버는 토큰에 이상이 없으면 요청한 정보를 응답한다.
4. 만약 액세스 토큰이 만료되었다면 클라이언트에게 만료사실을 알려주고, 클라이언트는 리프레시 토큰을 이용하여 액세스 토큰을 재발급 받아 새로 저장한다.

 

JWT 장점

• Header와 Payload를 가지고 Signature를 생성함으로써 데이터 위변조를 막을 수 있다.
• 인증 정보에 대한 별도의 저장소가 필요없다. (사실 실제 서비스하려면 로그아웃 + 리프레스토큰 저장을 위해 필요하다..)
• JWT는 자체적으로 기본 정보와 전달할 정보 및 토큰이 검증되었음을 증명하는 전자서명 등 필요한 정보를 가진다.
• 확장성이 우수하다. Stateless하기 때문에 분산 환경에서도 문제 없다.
• 모바일 어플리케이션에서도 사용할 수 있다. (앱은 쿠키저장소가 없음 - Web View가 아닐때)

 

JWT 단점

• 쿠키, 세션과 다르게 JWT는 토큰 길이가 길어 인증 요청이 많아질수록 네트워크 부하가 심해진다.
• Payload 자체는 암호화가 되지 않기 때문에 사용자의 중요한 정보를 담을 수 없다.
• 토큰을 탈취당하면 대처가 어렵다.
• 특정 사용자의 접속을 강제로 만료하기 어렵다. (추가적인 처리를 한다면 가능함)

 

Sliding Sessions

보안성과 편의성을 모두 잡을 수 있는 전략이다. 이 전략은 세션을 지속적으로 이용하는 유저에게 자동으로 만료 기한을 늘려주는 방법이다.

 

매 요청마다 새로운 토큰을 내려주는 것도 가능하지만, 글을 작성하다가 인증이 만료되는 무서운 경우를 막기 위해 글 작성을 시작할 때 발급해준다거나, 쇼핑몰에서 장바구니에 아티메을 담는 경우에 발급해주는 등의 여러 전략을 서비스마다 정해서 사용할 수 있다.
또 다른 방법으로는 클라이언트가 토큰의 발급 시간 (iat) 속성을 참조해서 갱신 요청을 하는 방법도 있다.

 

Hybrid 토큰 방식

사용자의 상태를 유지하지 않는 Stateless한 서비스를 운영할 때는 보안 이슈가 발생한다.

JWT가 제공하는 기본적인 Access Token외에 Refresh Token을 도입한다거나 Sliding Sessions 전략을 활용할 수 있다.

하지만 해당 방식을 이용하려면 추가적인 저장소가 필요하게 되어 Stateless하다고 좋아했던 장점은 없어지게 된다.

 

Refresh Token

클라이언트가 로그인 요청을 보내면 서버는 Access Token과 그보다 만료기간이 긴 Refresh Token을 함께 내려준다.

주로, Access Token은 30분 내외 그리고 Refresh Token은 2주에서 한달 정도의 만료 기간을 부여한다.

 

클라이언트는 Access Token이 만료되었다는 응답을 받게 되면, Refresh Token을 이용하여 Access Token을 재발급 받을 수 있다. 
이때, Refresh Token까지 같이 재발급 받을 수 있다.
혹여나, Refresh Token 까지 만료되었다면 다시 로그인을 해야한다.

 

Refresh Token을 사용한다는 것은 추가적인 저장소와 I/O 작업이 필요하다는 의미이며, 위에서 말했듯 기존의 JWT 장점을 살릴 수는 없다.  또한, Refresh Token을 탈취되면 안되므로 클라이언트는 보안이 유지되는 공간에 이를 저장해야 한다.

 

Refresh Token은 서버에서 따로 저장을 하고 있기 때문에 강제로 토큰을 만료시키는 것이 가능하다.

 

 

JWT의 시크릿 키

JWT 시크릿 키가 노출된다면 토큰을 생성하고 변조하여 악의적인 행동이 모두 가능해지므로 안전하게 설정할 필요가 있다.

시크릿 키의 경우 최소 512bits(약 64글자) 이상의 값으로 설정해야 한다.

 

암호화 알고리즘 같은 경우에는 기본적으로 HS256(HMAC with SHA-256)을 사용한다.
대칭키 암호화 알고리즘으로 시크릿 키가 암/복호화 모두에 사용된다. 하지만, 암/복호화 모두에 시크릿 키가 사용되다보니 탈취당했을 경우를 생각하면 비대칭키(공개키) 방식보다 안전하지 않을 수 있다.

 

따라서, RS256과 같은 비대칭키 암호화 알고리즘을 사용하는 것도 하나의 방법이다. 공개키가 탈취되어도 프라이빗 키를 모르면 공격자는 할 수 있는 것이 없기 때문이다. 하지만 더 리소스가 많이 든다는 단점이 있으니 Trade off를 잘 생각해서 선택하면 된다.