사용자의 인증 정보를 관리하는 방식은 크게 두 가지로 나뉜다.

• Session 기반 인증(서버 기반 인증)
  • Session: 유저가 로그인을 하게 되면, 서버측에서 유저가 로그인 중이라는 인증 정보를 기억하고 있어야 하는데, 이 정보를 Session이라 한다.
    
• Token 기반 인증
  

Session과 Token의 차이점
https://tansfil.tistory.com/58

Token 기반 인증의 등장배경

* 서버 기반 인증의 문제점

이전부터 수 많은 웹서비스에서 사용되어 오던 방식인 서버 기반 인증은 큰 규모의 어플리케이션이 등장하기 시작하며 걸림돌이 생기기 시작했다.

1. 세션을 유지하게 될 경우, 로그인 중인 유저의 수가 많아지면 성능에 무리가 간다.

2. 서버 확장이 어려워진다.

트래픽을 감당하기 위해 여러 서버 프로세스를 돌리거나, 여러 서버 컴퓨터를 추가하여 로드 밸런싱을 하는 경우, 세션을 사용하며 분산된 시스템을 설계하는 과정이 매우 복잡하다.

23.05.24 추가

해당 단점은, Redis 등의 Session storage 방식을 적용하여 해결할 수 있다.
참고 : https://velog.io/@kimcno3/Session-%EC%84%9C%EB%B2%84-%ED%99%95%EC%9E%A5%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EB%AF%BC

* Token 기반 시스템의 장점

토큰 기반 시스템은 stateless(무상태) 특성을 가지고 있다. 서버에서 더 이상 유저의 정보를 유지하지 않고, 유저가 회원 인증을 하게 될 때 토큰을 발급해줌으로서 유저가 자신임을 인증할 수 있게 해준다. 토큰에는 토큰의 유효기간, 정보를 담고 있으며 해싱 알고리즘을 통해 인증이 되어 있어 서버에서 검증을 통해 처음 서버가 발급해주었던 정보가 변조되지 않았음을 보장해 줄 수 있다.

서버를 확장하게 될 때 매우 용이해진다. 서버 시스템이 분산 되어 있어도 유저는 같은 토큰으로 서버에 요청을 하고, 서버는 DB조회 필요없이 토큰이 위조되지 않았는지만 검증하고 신뢰 처리를 하면 되기 때문이다.

플랫폼간 권한을 공유할 수 있다. 페이스북 / 구글 계정을 통한 다른 소셜 로그인이 가능한 이유가 구글과 페이스북에서 토큰 기반 인증을 사용하기 때문이다.

모바일 어플리케이션에서 사용하기에 편해진다. 세션 기반 인증을 사용하다면, 쿠키를 사용해야 하기 때문에 쿠키 매니저를 따로 관리해줘야 하지만, 토큰을 사용하면 웹 요청 API 헤더에 넣어서 사용하면 되기 때문에 쿠키 매니저를 사용할 필요가 없어진다.

단점 역시 존재한다.

* Token 인증의 단점

주로 보안 이슈가 많다.

1. 한번 발급된 토큰은 값을 수정하거나 폐기가 불가능하다.
   토큰 내에 모든 정보를 다 가지고 있기 때문에, 토큰을 잘못 발행해서 삭제하고 싶더라도, Signature만 맞으면 맞는 토큰으로 인식을 하기 때문에 서버에서는 한 번 발급 된 토큰의 정보를 바꾸는 일 등이 불가능하다. 그래서 토큰에 Expire time을 꼭 명시적으로 설정하고 refresh token / access token 2가지로 토큰을 분리하여, 유효시간이 짧은 access token을 주기적으로 재발행 하도록 해야 한다.

2. 클라이언트는 발급받은 토큰을 어디에 저장해야 하는가?
   웹 클라이언트가 토큰을 저장하기 위해 사용하는 공간은 크게 쿠키와 웹 스토리지 2가지로 나눌 수 있다.
   
   토큰값의 저장 위치는 아직까지도 의견이 분분하다. 정답은 없지만, 2가지 모두 장단점이 존재한다. 자세한 내용은 링크를 참조.
   https://lazyhoneyant.tistory.com/7