발전하는 춘배
회원 로그인 구현 시 인증 방식(쿠키, 세션, 토큰) 본문
개요
회원 로그인을 구현할 때 주로 사용되는 인증 방식에는 아래와 같이 크게 세 가지가 있다.
- 쿠키 방식
- 세션 방식
- 토큰 방식
각 방식은 고유한 장단점을 가지고 있어 적절히 선택해야 한다.
알아보도록 하자.
인증(Authentication)이 왜 필요할까
서버는 클라이언트 각각을 기억하지 못한다. 이는 다음과 같은 HTTP 프로토콜의 특성에 기인한다.
- 비연결성 (Connectionless):
실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 연결을 끊는다. 최소한의 자원으로 서버를 유지하기 위함이다. - 무상태 (Stateless):
서버가 클라이언트의 상태를 저장하지 않는다. 따라서 응답과 요청이 독립적이다.
따라서 로그인과 같이 클라이언트가 자신이 누구인지 서버에게 알려야 하는 기능을 구현하기 위해서는 인증을 통해 상태(State)를 유지해야 한다.
쿠키 Cookie
- 동작 방식
- 클라이언트가 로그인 요청
- 서버가 쿠키를 발급하여 클라이언트에게 응답
- 클라이언트는 쿠키를 로컬(브라우저)에 저장하다가 이후 HTTP 요청 시 헤더에 담아 전송
- 장점
- 구현 용이: 다른 방식에 비교했을 때 구현이 쉽고 간편하다.
- 구현 용이: 다른 방식에 비교했을 때 구현이 쉽고 간편하다.
- 단점
- 보안 취약: XSS(Cross-Site Scripting)나 CSRF(Cross-Site Request Forgery) 공격에 취약할 수 있다. 따라서 쿠키에 `HttpOnly` 속성을 추가하여 JavaScript로 쿠키에 접근하여 탈취하는 것을 막아 XSS 공격을 방지해야 한다. 또한 `SameSite=Strict` 속성을 통해 쿠키가 동일한 사이트 내에서만 전송되도록 제한하여 CSRF 공격을 방지해야 한다. 그럼에도 불구하고 쿠키는 클라이언트의 브라우저 내에 저장되기 때문에 본질적으로 보안에 취약할 수밖에 없다.
세션 Session
- 동작 방식
- 클라이언트가 로그인 요청
- 서버가 사용자를 식별하는 정보를 담은 세션 ID를 생성하여 Set-Cookie 헤더에 담아 응답. 세션 정보는 서버측 DB에 저장.
- 클라이언트는 세션 ID 쿠키를 로컬(브라우저)에 저장하다가 이후 HTTP 요청 시 헤더에 담아 전송
- 서버는 DB에서 해당 세션을 찾아 송신자 식별 가능
- 장점
- 보안 강화: 세션 데이터가 서버에 저장되고 관리되므로 클라이언트 측에서 데이터가 노출되지 않는다. 만약 세션 ID가 해커에게 탈취된다고 하더라도 서버측에서 해당 세션을 무효 처리할 수 있다.
- 보안 강화: 세션 데이터가 서버에 저장되고 관리되므로 클라이언트 측에서 데이터가 노출되지 않는다. 만약 세션 ID가 해커에게 탈취된다고 하더라도 서버측에서 해당 세션을 무효 처리할 수 있다.
- 단점
- 서버 부하: 모든 세션 데이터가 서버에 저장되기 때문에 서버에 부하가 발생할 수 있다.
- 확장성 문제: 수평 확장(Scale out) 등의 이유로 서버가 여러 대일 경우, 최초 세션이 생성된 서버와 그 이후의 요청을 받은 서버가 다를 수 있는데 이 때 세션이 불일치하는 문제가 발생한다. 세션 불일치 문제를 해결하기 위해 Sticky Session, Session Clustering, Session Storage의 방법을 적용할 수 있지만 토큰 방식과 비교했을 때 확장성이 떨어질 수밖에 없다.
토큰 Token (ex: JWT)
- 동작 방식
- 클라이언트가 로그인 요청
- 서버가 사용자를 식별하는 정보를 담은 토큰을 발급
- 클라이언트는 이후 HTTP 요청 시 토큰을 헤더에 담아 전송
- 서버는 요청 헤더의 토큰을 검증하여 사용자 식별
- 장점
- 무상태 (Stateless): 토큰은 서버측에 저장되지 않으므로 HTTP의 무상태 특성을 유지할 수 있다.
- 서버 부하 감소: 세션과 비교했을 때, 토큰 방식은 받은 토큰을 검증만 하면 되므로 DB 조회가 필요 없어 부하가 적다.
- 높은 확장성: 무상태 특성이 유지되기 때문에 세션 방식에서 나타나는 세션 불일치 문제로부터 자유롭다. 특히 웹뿐만 아니라 모바일 앱 또는 API 등의 다양한 환경에서도 사용이 가능하다는 장점이 있다.
- 무상태 (Stateless): 토큰은 서버측에 저장되지 않으므로 HTTP의 무상태 특성을 유지할 수 있다.
- 단점
- 보안 문제: 토큰은 서버에서 전혀 관리되지 않기 때문에, 만료되지 않은 토큰이 노출되어 해커에게 탈취당할 경우 무효화하기가 어렵다. 이를 막기 위해 토큰의 만료 시간을 짧게 설정하거나, 리프레시 토큰을 사용해 만료된 토큰을 갱신하는 방식을 사용하면 좋다. 또 블랙리스트나 화이트리스트를 사용해 토큰을 서버측에서 무효화할 수 있도록 할 수 있다.
어떤 방식을 사용할까
각각의 장단점이 명확하기 때문에, 만들고자 하는 애플리케이션의 특성에 따라 선택이 달라진다.
- 간단한 웹 애플리케이션: 서버 기반의 간단한 웹 애플리케이션의 경우, 확장성이 비교적 덜 중요하기 때문에 보안에 중점을 둔 세션 방식이 적절하다.
- 대규모, 분산 시스템: 하나의 API 서버로 웹, 앱, IoT기기 등 여러 종류의 클라이언트를 지원해야 하는 경우, 확장성에 중점을 둔 토큰 방식이 적절하다.
- 보안이 중요할 경우: 금융 서비스처럼 보안이 중요한 경우 역시 세션 방식이 적절하다.