인증 방식 비교(서버 기반 인증, 토큰 기반 인증)

서버 기반 인증(Session, Cookie)

서버 측에서 사용자들의 정보를 기억하기 위해 세션을 유지해야 하고, 세션을 메모리, 디스크, 데이터베이스 등을 통해 관리한다. 클라이언트로부터 요청을 받으면 클라이언트의 상태 정보를 저장하여 유지해야 하므로 Stateful한 구조를 가진다.

[ 인증 방식 ]

1. 사용자가 로그인 시 올바른 사용자임을 확인하고, 고유한 세션 ID 값을 부여해 세션 저장소에 저장하고 클라이언트에게 발급해준다.
2. 클라이언트는 서버에서 해당 세션 ID를 받아 쿠키에 저장하고, 인증이 필요한 요청을 할 때 마다 쿠키를 HTTP 헤더에 담아 전송한다.
3. 서버에서는 세션 ID를 받아 세션 저장소와 비교해 올바른 요청인지 확인한다.
4. 인증이 완료되고 서버는 요청에 응답한다.

[ 장점 ]

• 중요한 정보는 서버에 있기 때문에 쿠키 자체(세션 ID)에는 유의미한 값을 가지고 있지 않다.

[ 단점 ]

• 해커가 훔친 쿠키를 이용해 HTTP 요청을 보내면 서버에서는 올바른 사용자가 보낸 요청인지 알 수 없다. (세션 하이재킹 공격)
• 세션을 서버의 메모리 혹은 별도의 세션 저장소에 저장하는데, 사용자가 증가함에 따라 과부하를 줄 수 있다.
• 사용자가 늘어났을 때 세션을 분산시키는 시스템을 설계할 수 있지만 과정이 매우 어렵고 복잡하다.
• CORS 문제 : 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 여러 도메인에서 관리하기 번거롭다.

 

 

토큰 기반 인증(JWT)

인증받은 사용자에게 토큰을 발급해주고, 서버에 요청을 할 때 HTTP 헤더에 토큰을 함께 보내 인증받은 사용자(유효성 검사)인지 확인한다.

사용자의 인증 정보를 서버에 저장하거나 상태를 유지하지 않으므로 Stateless한 구조이다.

[ 인증 방식 ]

1. 사용자가 로그인 시 올바른 사용자임을 확인하고, 클라이언트에게 Access Token(JWT)을 발급해준다.
2. 클라이언트는 전달받은 토큰을 저장해 두고, 인증이 필요한 요청마다 토큰을 HTTP 헤더에 담아 보낸다.
3. 서버에서는 암호화된 토큰을 복호화 해 올바른 요청인지 확인한다.
4. 인증이 완료되고 서버는 요청에 응답한다.

[ 장점 ]

• 서버 기반 인증 시스템은 저장소의 관리가 필요하지만, 토큰 기반은 Access Token을 발급해준 후 요청이 들어오면 검증만 해주면 되기 때문에 추가 저장소가 필요 없다. 즉 Stateless 하다.
• 쿠키를 사용함으로 인해 발생하는 취약점이 사라진다. 하지만, 토큰을 사용하는 환경에서의 취약점에 대비해야 한다.
• 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다. Ex) facebook, Google 등

[ 단점 ]

• 이미 발급된 JWT를 돌이킬 수 없다. 서버 기반 인증 시스템처럼 저장소를 사용하는 경우에는 해당 세션이 악의적으로 사용될 경우 지워버리면 되지만, JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하다.
• 즉, 유효기간이 지나기 전까지 실컷 털릴 수 있다.
• JWT의 길이가 길다. 인증이 필요한 요청이 많아질수록 서버의 자원 낭비가 발생한다.