세션 기반 인증과, 토큰 기반 인증에 대해 알아보자!
자세히 알기 위해서는, 우선 인증이 무엇인지에 대해 알아야 한다.
인증
어떤 사용자 또는 장치의 신원을 확인하는 과정
예시로, 신원을 확인하기 위해 신분증을 제출하는 경우 등을 인증절차라고 할 수 있다.
인가
어떤 개체가 어떤 리소스에 접근할 수 있는지, 어떤 동작을 수행할 수 있는지 검증하는 것
접근 권한을 얻는 일을 말한다.
예시로, 신원을 확인하여 회원가입을 진행한 A와 B가 존재한다고 하자. A가 게시글을 작성하였을 때, B는 A가 작성한 게시글에 대해 수정과 삭제의 권한을 가지고 있지 않다. 타인의 리소스에 대해 인가되어 있지 않기 때문이다.
✨ 인증은 인가로 이어지지만, 인가는 인증으로 이어지지 않는다.
세션 기반 인증
세션이란?
서버가 저장하는 사이트 방문자들에 대한 기록이다.
id, ip 주소, 마지막 방문 시기, 사용한 브라우저 등의 정보가 담겨 있다.
세션 기반 인증
세션을 사용한 인증 방식이다.
유저가 로그인 할 시, 서버는 세션 정보를 기록한 뒤 세션을 식별하는 id를 Set-Cookie로 클라이언트에 응답하게 된다.
클라이언트가 서버에 요청할 때, 서버에서 응답한 쿠키를 자동으로 포함하게 된다.
서버는 클라이언트의 쿠키에 담긴 세션 id만 확인해서 방문자의 신원을 파악할 수 있다!
일정한 기간이 지나거나, 클라이언트에서 로그아웃 요청을 보낼 경우 해당 세션이나 로그인 유저를 만료 처리한다.
토큰 기반 인증
인증 토큰
유저에 대한 정보를 암호화한 문자열이다.
특정 콘텐츠에 대해 접근할 수 있게 해주기 때문에 Access Token이라고도 한다.
JWT (JSON Web Token) 형식을 가장 많이 사용하고 있다.
토큰 기반 인증
유저의 로그인 상태를 저장하고, 요청이 올 때마다 저장 및 확인하지 않고도 유저를 식별할 수 있다.
대신, 토큰 자체를 해석해서 사용하게 된다.
유저가 로그인 할 시, 유저를 식별할 수 있는 id, 만료일 등의 내용이 담긴 토큰을 만들어 클라이언트에게 응답한다.
JWT의 경우 디지털 서명이 존재해 토큰의 내용이 위변조 되었는지 서버측에서 확인이 가능하다.
이후 클라이언트는 응답으로 받은 토큰을 서버에 요청할 때 Authorization 헤더에 담아 전송한다.
서버는 클라이언트의 토큰을 비밀키를 사용해 해석, 유효성 검증 및 유저를 특정한다.
만료 시간이 지나지 않고, 토큰을 가지고 있는 경우에는 항상 로그인 상태를 유지할 수 있다. 로그아웃을 하고 싶으면 클라이언트에서 저장한 토큰을 삭제하면 된다.
세션과 토큰 인증의 차이
사이즈
세션의 경우 Cookie 헤더에 세션 id만 보내면 되므로 트래픽을 적게 사용한다.
토큰의 경우(JWT) 사용자 인증 정보, 토큰의 발급 시각, 만료 시각, 토큰의 id 등의 정보를 담으므로 세션 id에 비해 정보가 방대하여 더 많은 네트워크 트래픽을 사용한다.
효율성
토큰 기반 인증의 장점이다.
세션 기반 인증의 경우, 서버는 항상 로그인 세션을 저장하고 매 리퀘스트가 일어날 때 유저가 누구인지 비교해야 한다.
토큰 기반 인증의 경우 토큰 자체 내용을 해석하면 되기에 효율적으로 작동이 가능하다.
유연성
토큰 기반 인증의 경우, 토큰을 발행하는 방법이 똑같고, 시크릿 키만 존재한다면 발행을 한 곳과 확인을 하는 곳이 달라도 유연하게 인증이 가능하다.
RESTful API
세션 정보와 같이 서버가 상태 정보를, 예를 들어 유저가 로그인을 했는지 안 했는지를 저장하고 있는 걸 stateful하다고 표현한다.
REST에 부합하기 위해서는, 서버가 상태 정보를 저장하지 않는 특성(stateless)이 있어야 한다.
서버는 클라이언트에서 보내는 정보만으로 충분히 상태를 파악할 수 있어야 한다!
이 기준으로 보았을 때, 토큰 기반 인증이 더 어울린다고 할 수 있다.
무효화
세션 기반 인증의 장점 중 하나이다.
서버에서 세션 데이터를 따로 관리하므로 특정 세션을 손쉽게 무효화가 가능하다.
안전장치를 더 쉽게 사용할 수 있다는 점으로 이해하도록 하자.
참고
Using Session Cookies Vs. JWT for Authentication
코드잇-세션vs토큰 기반 인증
