세션, 쿠키, 토큰
노마드 코더의 세션 vs 쿠키 vs 토큰 동영상을 보고 잘못 사용하고 있던 것 같아 정확한 사용법과 정의를 정리해보고자한다.
Cookie
서버와 클라이언트가 대화하기 위한 수단
- 브라우저가 서버와 연결이 되었을 때 브라우저에서 쿠키를 생성하고, response 할 때 쿠키를 담아서 전송
- 특정 호스트에서 생성된 쿠키는 이후 모든 요청마다 서버로 전송
- 쿠키에 담긴 데이터는 브라우저에서 관리
Session
서버와 클라이언트의 연결이 활성화된 상태
- 클라이언트가 서버와 통신을 시작하면 서버는 해당 클라이언트에 대해 유일한 값인 세션 id를 부여, 세션 스토리지에 세션 정보를 저장
- 클라이언트는 쿠키를 통해 해당 세션 id를 기억
- 이후 클라이언트가 어떤 요청을 보낼 때마다 헤더의 쿠키에 세션 id를 담아서 전송함.
- 서버는 클라이언트가 보낸 요청의 쿠키에 담긴 세션 id와 세션 스토리지에 담긴 세션 id를 대조해 인증 상태를 판단함.
- 각 클라이언트마다 유니크한 세션 객체가 주어지고, 이 세션 객체에 데이터를 담아 관리할 수 도 있음.
- 세션을 사용하지 않고 쿠키만으로 어떤 데이터를 주고받는다면, 클라이언트는 이미 모든 데이터를 알고 있다는 뜻
쿠키와 세션은 결국 사용자에게
- 적절한 사용자 경험을 제공하고 ('일주일 간 다시 보지 않기', 로그인 유지하기 등)
- 보안을 유지하기위해 사용된다.(인증 상태 관리)
Token
인증을 위해 사용되는 암호화된 문자열
- 사용자가 인증에 성공하면 서버는 토큰을 생성해서 클라이언트로 보낸다.
- 토큰도 세션과 마찬가지로 사용자가 보내는 요청에 포함이 됨.
- 세션 인증에서는 서버가 세션 id를 저장하고 클라이언트가 쿠키에 실어 보낸 세션 id와 대조해서 확인하는 반면, 토큰을 사용하면 요청을 받은 서버는 토큰이 유효한지를 확인만 함. http통신의 stateless 한 성격과 더 적합한 인증 방식.
세션 vs 토큰
세션은 서버에서 사용자를 강제로 추방할 수 있기 때문에 보안에 좀 더 용이하지만, 세션 스토리지라는 DB를 따로 물고 있어야하기 때문에 비용이 비교적 높다.
반면에 토큰은 추가 비용이 발생하지는 않지만 같은 유저의 한 기기에서만 로그인과 같은 기능을 제공할 수 없다는 단점이 있다. 또한, 토큰이 탈취당한 경우에 이를 만료시간 이전에 강제로 만료시킬 방법이 없다.
이를 해결 하기 위해, 토큰을 access-token 과 refresh-token 으로 나누어 제공하는 방법을 사용하기도 하지만 짧은 만료 시간의 access-token 마저 그 짧은 시간을 지나기 전에는 강제로 만료시킬 방법이 없기 때문에 완벽하지는 않다.
다음은 장고 애플리케이션으로 웹 서비스를 만들며 사용한 인증(Authorization) 절차이다.
Authorization 절차
- Authentication(로그인) 절차를 통해 access token을 생성한다. access token에는 유저 정보를 확인할 수 있는 정보가 들어가 있어야 한다.
- 유저가 request를 보낼때 access token을 첨부해서 보낸다.
- 서버에서는 유저가 보낸 access token을 복호화 한다.
- 복호화된 데이터를 통해 user id를 얻는다.
- 유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
나 역시도 위와 같은 방식을 사용하고 있는데, 복호화된 access token을 통해 user_id 를 얻어내는 방식이 마치 세션 방식과 비슷하여 두 방식의 차이를 느끼기가 어렵다.
가장 큰 차이점은 DB가 따로 존재하는지 아닌지이다.
세션 방식은 로그인(Authentication)이 완료되면 세션 스토리지라는 DB에 로그인 된 계정들의 레코드가 생성된다.
그러나 토큰 방식은 기존 유저 DB에 토큰 칼럼에 값이 들어가는 것이므로 추가적인 레코드가 생성되거나 하지는 않게된다.
References
https://tofusand-dev.tistory.com/89