세션 기반 인증 vs 토큰 기반 인증, 그리고 쿠키🍪

세션? 토큰? 쿠키?

인증 방식에 대해 이야기할 때 헷갈리는 개념들을 정리해보고자 합니다.

HTTP는 무상태!

우선 HTTP 프로토콜이 무상태(stateless)라는 것을 이해해야 합니다.

HTTP 프로토콜로 웹을 통해 통신해야 할 때, 우리가 보내는 각각의 요청은 독립적입니다.

요청이 끝나면 서버는 클라이언트의 정보를 잊어버리고, 요청을 보낼 때마다 클라이언트가 누군지 알려줘야 합니다.

서버에게 요청을 보낼 때 클라이언트가 누군지 알려주는 방식으로 대표적으로 세션과 토큰이 있는 것입니다.

세션 인증 방식과 토큰 인증 방식의 로그인 방법에 대해 이야기 해보겠습니다.

세션 인증 방식으로 로그인을 하는 과정은 다음과 같습니다.

세션은 세션 ID를 생성하고 저장하기 위한 데이터베이스(주로 Redis)가 필요합니다.

데이터베이스에 인증 정보를 저장하기 때문에 사용자 수가 늘어날수록 필요한 데이터베이스 자원도 늘어나는 단점이 있습니다.

하지만 필요에 따라 서비스에 다음과 같은 새로운 기능들을 추가할 수 있는 장점도 있습니다.

토큰 인증 방식으로 로그인을 하는 과정은 다음과 같습니다. JWT(JSON Web Token)을 예로 들어보겠습니다.

토큰 인증 방식은 별도의 데이터베이스가 필요하지 않습니다.

토큰 자체에 사용자 정보를 담아서 서명하기 때문에, 요청이 들어올 때마다 토큰을 검증해서 그 안에 담긴 정보를 확인할 수 있습니다.

하지만 JWT 같은 토큰은 암호화된 것이 아닙니다.

누구나 페이로드에 담긴 정보를 확인할 수 있기 때문에 비밀번호와 같은 민감한 데이터는 담으면 안 됩니다.

그럼 쿠키는 뭘까요?

쿠키는 세션이나 토큰 같은 인증 정보를 전달하는 매개체일 뿐입니다.

만약 쿠키를 사용해 JWT를 전달한다고 한다면 로그인 과정은 다음과 같습니다.

이는 JWT가 아니라 세션을 사용한다고 해도 마찬가지입니다.

서버에서는 쿠키를 보낼 때 쿠키를 보낼 수 있는 도메인, 만료시간 등을 설정해서 보냅니다.

하지만 쿠키는 브라우저 스펙이기 때문에 웹 브라우저에서만 동작합니다.

iOS, Android와 같은 네이티브 앱에서는 쿠키가 없습니다.

이럴 때는 요청 헤더에 Authorization: <type> <credentials> 형식으로 보낼 수 있습니다.

HTTP 프로토콜에서는 Authorization 헤더가 사용자 인증을 위한 표준 위치이고, 토큰 기반 인증일 경우 type에 Bearer를 사용하는 것을 권장합니다. [참고1] [참고2]

Cookie와 Authorization 헤더는 인증정보를 전달하는 매개체입니다.

마지막으로 이 둘의 차이를 정리해보겠습니다.

웹 브라우저에만 동작합니다.
브라우저에서 인증 정보를 자동으로 포함해서 요청을 보내게 할 수 있다는 장점이 있습니다.
- axios : { withCredentials: true } 옵션 추가
- Fetch API : { credentials: "include" } 옵션 추가
매 요청마다 인증 정보가 자동으로 포함되기 때문에 CSRF 공격의 위험이 있습니다.
- 👉 CSRF 토큰을 사용하거나, Referer Header 검증을 추가하여 CSRF 공격을 방어할 수 있습니다.
Javascript 상에서 document.cookie로 접근하여 XSS 공격의 위험도 있습니다.
- 👉 서버 측에서 쿠키를 설정할 때 httpOnly 옵션을 추가하여 Javascript로 접근하지 못하게 해야 합니다.

	세션 기반 인증	토큰 기반 인증
장점	- 보안을 위한 서비스 확장이 가능함.	- 별도의 데이터베이스 자원이 필요하지 않음.
단점	- 세션을 저장하기 위한 데이터베이스 자원이 필요함.	- 보안을 위한 서비스 확장은 어려움. - 페이로드에 민감 데이터를 담지 않도록 주의가 필요함.

	Cookie	Authorization Header
특징	- 웹 브라우저에만 동작함. - 서버에 요청시 인증정보를 자동으로 포함시킬 수 있음.	- 네이티브 앱 클라이언트를 지원할 경우 사용 가능함. - 토큰 기반 인증일 경우 Bearer를 사용하는 것을 권장함.
장점	- 웹 클라이언트 개발 측에서 인증 정보 보관 방법을 따로 고려하지 않아도 됨.	- 인증 정보를 자동으로 포함하지 않으므로 CSRF 공격에 비교적 안전함.
단점	- CSRF, XSS 공격에 대한 방어가 필요함.	- 클라이언트 개발 측에서 인증 정보 보관 방법을 따로 고려해야 함. - 클라이언트가 웹 브라우저일 때 세션 스토리지나 로컬 스토리지를 사용할 경우 XSS 공격 위험성 있음.