HTTP는 stateless한 특성을 가지므로 각 통신의 상태가 저장되지 않는다.
그렇다면 웹 서비스에서 새 페이지를 요청할 때마다 매번 로그인을 해야할까?
이 문제를 해결하기 위한 대표적인 도구로 세션과 토큰이 있다.
일반적인 웹 서비스에서 사용자의 로그인 시도 시 서버에서 일치하는 사용자 정보를 찾았다면 인증 확인의 표시로 세션이나 토큰을 발급해주는데, 각 프로세스와 장단점은 다음과 같다.
Session(세션)
프로세스
로그인 성공 시 서버는 세션 아이디라는 데이터를 만드는데, 사용자는 서버로부터 이러한 세션 아이디를 전달받아 쿠키로 저장하고, 이후 모든 요청에 함께 전달한다. 서버는 요청을 받으면 세션 아이디가 적혀 있는지 확인한다. 세션 아이디가 있다면 보관하고 있던 세션 아이디 중 동일한 정보가 있는지 확인한다. 유효한 세션이라면 적절한 응답을 보내주고, 없다면 401 에러를 반환한다.
장단점
이러한 세션의 장점은 매 요청마다 세션 아이디를 빠르게 확인할 수 있다.
그러나 동시 접속하는 사용자가 많아진다면 메모리 공간이 부족해져 서버 부하가 심해질 수 있다. 또한, 세션 아이디를 따로 저장해둔다는 점에서 stateless한 http의 특성을 위배하게 된다.
이러한 세션의 대안으로 토큰을 발급해주는 방법이 있다.
Token(토큰)
프로세스
사용자 로그인 성공 시 서버는 비밀키로 발행한 토큰을 사용자에게 전달하고, 사용자는 이를 쿠키로 저장해두어 매 요청마다 전달하면 서버는 자기가 발급한 토큰임을 알아볼 수 있기 때문에 사용자의 요청을 허가하는 방식이다.
세션 기반 인증과 가장 큰 차이는 세션 기반 인증은 인증 정보를 서버에 저장하는 방식이고, 토큰 기반 인증은 인증 정보를 클라이언트가 직접 들고 있는 방식이다. 이 때, 인증 정보는 토큰의 형태로 로컬 스토리지 혹은 쿠키에 저장된다.
장단점
토큰은 세션처럼 세션 아이디를 메모리에 보관하고 있을 필요가 없고, 토큰은 클라이언트에 저장되기 때문에 서버 부하를 줄일 수 있다.
그러나 일단 발급되면 만료 전까지는 따로 토큰을 통제할 수 없어 토큰을 탈취당할 경우 보안 문제가 발생할 수 있다. 이러한 피해를 줄이기 위해 토큰도 쿠키처럼 만료 기간을 정할 수 있으므로 만료 시간을 짧게 지정하거나 유효기간이 다른 2개의 토큰을 두어 위험을 줄일 수 있다.
JWT (Json Web Token)
가장 대표적인 토큰 기반 인증 방식으로, 인증에 필요한 정보들을 암호화시킨 JSON 토큰이다.
이러한 JWT 기반 인증은 토큰을 HTTP Header에 실어 서버가 클라이언트를 식별하는 방식으로, 사용자가 JWT를 서버로 전송하면 서버는 토큰 내부에 위변조 방지를 위한 개인키로 서명된 전자서명을 검증하여 검증 완료 시 적절한 응답을 반환한다.
Structure
JWT는 Header, payload, Signature 3가지 구성요소로 이루어져 있으며 점(.)으로 구분되어 있다.
- Header : JWT에서 사용할 타입과 해시 알고리즘 종류 명시
- Payload : 사용자 정보와 같은 클레임 정보들이 들어간다. 클레임 정보는 이름과 값으로 구성되어 있다. 대표적으로 Registered claims(발행자, 만료시간 등), Public claims, Private claims 가 있다.
- Signature : Header, Payload를 Header에 명시된 해시 알고리즘을 적용하여 암호화한 값과 개인키로 서명한 전자서명이 담겨있다.
Header와 Payload는 단순히 인코딩된 값이므로 복호화 및 조작할 수 있지만, Signature는 서버측의 비밀키가 유출되지 않는 이상 복호화할 수 없다. 따라서 Signature는 토큰의 위변조 여부를 확인하는 데 사용된다.
