[Spring Security] 인증 방식 비교(서버 기반 인증, 토큰 기반 인증)

API를 이용한 웹서비스를 개발할 때, 토큰을 사용하여 사용자들의 인증 작업을 처리하는 것이 가장 좋은 방법이라고 알고있어 토이 프로젝트에서 구현해보고 있습니다.

이번 포스팅에서는 서버 기반 인증 시스템의 개념과 한계, 그리고  토큰 기반 인증 시스템의 장단점에 대해 알아보도록 하겠습니다.

 

---

 

서버(세션) 기반 인증(Session, Cookie)

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

 

[ 인증 방식 ]

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

[ 장점 ]

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

[ 단점 ]

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

 

토큰 기반 인증(JWT)

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

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

최근에는 Json 포맷을 이용하는 JWT(Json Web Token)을 주로 사용합니다.

 

[ 인증 방식 ]

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

[ 장점 ]

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

[ 단점 ]

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

 

 

---

 

 

참고

- 스터디원 제리👏 감사합니다^^

- https://mangkyu.tistory.com/55