[JWT] 서버 기반 인증 vs 토큰 기반 인증

 서버 기반 인증 

 서버 기반 인증 시스템의 흐름 

기존의 인증 시스템에서는 서버측에서 유저들의 정보를 기억하고 있어야 한다. 유저들의 정보를 기억하기 위해서 세션을 이용하는데, 이 세션을 유지하기 위해서는 메모리/디스크/데이터베이스 시스템과 같은 여러가지 방법을 이용했다.

서버 기반 인증 시스템의 흐름을 보자면 다음과 같다.

이런 방식의 인증 시스템은 아직도 많이 사용되고 있다.

하지만, 서버 기반 인증 시스템은 아래와 같은 문제를 가진다.

 

 서버 기반 인증의 문제점 

세션

유저가 인증을 할 때, 서버 측에 이러한 정보를 저장해야 하며, 이를 세션이라고 부른다.

대부분의 경우엔 메모리에 이를 저장하나 로그인 중인 유저의 수가 늘어난다면, 서버 측 메모리가 과부화가 올 것이다.

이를 피하기 위해 데이터베이스를 이용하는 방식이 있지만, 이 또한 유저의 수가 많으면 데이터베이스 성능에 무리를 줄 수 있다.

 

확장성

세션을 사용하면 서버를 확장하는 것이 어려워진다. 서버의 확장이란 단순히 서버의 사양을 업그레이드 하는 것이 아니라, 더 많은 트래픽을 감당하기 위해 여러 개의 프로세스를 돌리거나, 여러 대의 서버 컴퓨터를 추가하는 것을 의미한다. 세션을 사용하면서 분산 시스템를 설계하는 것이 불가능하지는 않지만 과정이 매우 복잡해진다.

 

CORS(Cross-Origin Resource Sharing)

웹 어플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있다. 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거로워진다.

 

 토큰 기반 인증 

토큰 기반 인증 시스템은 stateless(무상태), 즉 상태유지를 하지 않는다. 이 인증 기반 시스템에서는 더 이상 유저의 인증 정보를 서버나 세션에 담아두지 않는다. 이 개념 하나로도 위에서 언급한 많은 문제점들이 해소된다.

 

세션이 존재하지 않으니, 유저들이 로그인 되어있는지 상태 체크를 하지않아도 되며, 서버 확장도 용이해진다.

 

토큰 기반 인증 시스템의 흐름

토큰 기반 인증의 구현 방식은 시스템마다 크고작은 차이가 있지만, 대략적으로 다음과 같다.

1. 유저가 아이디와 비밀번호로 로그인을 한다.
2. 서버 측에서 해당 계정정보를 검증한다.
3. 계정정보가 정확하다면, 서버 측에서 유저에게 signed 토큰을 발급해준다. (여기서 signed의 의미는 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature를 지니고 있다는 것이다.)
4. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때마다 해당 토큰을 서버에 전달한다.
5. 서버는 토큰을 검증하고, 요청에 응답한다.

웹 서버에서 토큰을 서버에 전달할 때는, HTTP 요청의 헤더에 토큰 값을 포함시켜 전달한다.

 

 토큰 기반 인증의 장점 

무상태(stateless) & 확장성(scalabiltity)

토큰은 클라이언트 사이드에 저장하기 때문에 완전히 stateless하며, 서버를 확장하기에 매우 적합한 환경을 제공한다.

만약 세션을 서버측에 저장하고, 서버를 여러대를 사용하여 요청을 분산했을 경우에는 유저는 처음 로그인했던 그 서버에만 요청을 보내야한다. 하지만 토큰 사용 시 어떠한 서버로 요청이 와도 상관이 없다.

 

보안성

클라이언트가 서버에 요청을 보낼 때, 더 이상 쿠키를 전달하지 않으므로 쿠키 사용으로 인해 발생하는 취약점이 사라진다.

하지만, 토큰을 사용하는 환경에서도 취약점이 존재할 수 있으니 언제나 취약점에 대비해야 한다. (참조)

 

확장성(Extensibility)

여기서 확장성은, Scalability와 또 다른 개념이다. Scalability는 서버를 확장하는 것을 의미하는 반면, Extensibility는 로그인 정보가 사용되는 분야를 확장하는 것을 의미한다.

토큰을 사용하여 다른 서비스에서도 권한을 공유할 수 있다.

예를 들어, 한 사이트에서 Facebook, LinkedIn, GitHub, Googe 계정으로 로그인이 가능하다. 토큰 기반 시스템에서는, 토큰에 선택적인 권한만 부여하여 발급할 수 있다. (예를 들어 로켓펀치에서 페이스북 계정으로 로그인을 했다면, 프로필 정보를 가져오는 권한은 있어도 포스트를 작성할 수 있는 권한은 없다.)

 

여러 플랫폼 및 도메인

서버 기반 인증 시스템의 문제점 중 CORS에 대응되는 부분이다. 어플리케이션과 서비스의 규모가 커지면, 다양한 디바이스 호환과 서비스 제공을 하게된다. 토큰을 사용하면, 디바이스, 도메인에 상관없이 토큰만 유효하다면 요청이 정상적으로 처리된다. 서버 측에서 어플리케이션의 응답 부분에 다음 헤더만 포함시켜주면 된다.

Access-Control-Allow-Origin: *

이런 구조라면, assets 파일들(image, css, js, html 파일 등)은 모두 CDN에서 제공을 하도록 하고, 서버 측에서는 오직 API만 다루도록 설계할 수도 있다.

 

웹 표준 기반

토큰 기반 인증 시스템의 구현체인 JWT는 웹 표준 RFC 7519에 등록되어 있다. 따라서 여러 환경에서 지원이 되며 (.NET, Ruby, Java, Node.js, Python, PHP …) 수많은 회사의 인프라스트럭쳐에서 사용 되고 있다. (구글, 마이크로소프트 …)

 

참고자료:

[JWT] 토큰(Token) 기반 인증에 대한 소개 | VELOPERT.LOG