쿠키 / 세션 / 토큰 / 캐시
Q> 쿠키와 세션은 왜 같이 사용되는가?
A> 세션이 보안성이 좋다고 무분별하게 만들면 서버의 자원에 한계가 있기 때문에 메모리 문제가 발생한다. 각각의 장단점을 활용하여 같이 사용하면 최고의 성능을 낼 수 있다.
앞선 포스팅에서 설명한 쿠키/세션에 대해 정리된 표이다.
쿠키 / 세션과 관련된 자세한 내용은 포스팅 내 쿠키(Cookie)와 세션(Session)을 참고하세요.
지난포스팅에 이어 이번에는 토큰(jwt)에 대해 정리하도록 한다.
그리고 JWT 토큰
토큰이란?
- 토큰은 서버가 각각의 클라이언트를 누군지 구별할 수 있도록 하는. 즉, 인증을 위해 사용되는 암호화된 문자열
- 쿠키/세션 방식과 유사하게 HTTP 요청 헤더에 토큰을 실어 서버가 클라이언트를 식별한다. 그러면 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증 과정을 처리하게 된다.
Q> 지금까지만 봤을 때에는 쿠키/세션 방식과 동일해보이는데 어떤 차별점이 있나요?
A> 기존의 세션(서버) 기반 인증 방식은 서버가 파일이나 데이터베이스에 세션 정보를 가지고 있어야 하고, 이를 조회하는 과정이 필요하기 때문에 대규모 서비스가 될수록 서버에 많은 오버헤드가 발생한다.
반면에 토큰 인증 방식은 서버가 아닌 클라이언트에 저장되기 때문에 메모리나 스토리지 등을 통해 세션 정보를 관리했던 쿠키/세션 방식과는 다르게 서버의 부담을 덜 수 있다.자세한 건 뒤에서…!
JWT (Json Web Token)
- JWT란 JSON Web Token의 약자로 JSON 객체를 사용하여 인증에 필요한 정보들을 암호화시킨 토큰. 다시 말해, JWT는 유저를 인증하고 식별하기 위한 토큰(Token)기반 인증 방식
- JWT 기반 인증은 쿠키/세션 방식과 유사하게 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별
- 앞서 말한대로 JWT토큰을 사용하면 JWT토큰을 클라이언트에 저장하고 요청시 단순히 HTTP 헤더에 토큰을 첨부하는 것만으로도 단순하게 데이터를 요청하고 응답을 받을 수 있기 때문에 RESTful과 같은 무상태(Stateless)인 환경에서 사용자 데이터를 주고 받을 수 있게 된다.
- JWT 토큰은 토큰 내부에 위변조 방지를 위해 개인 키를 통한 전자서명도 있는데 사용자가 JWT를 서버로 전송하면 서버는 서명을 검증하는 과정을 거치게 되며 검증이 완료되면 요청한 응답을 주는 형태로 동작되게 된다.
- RFC 7519. JSON Web Token (JWT)
- JWT의 구조
- JWT는 Header, Payload, Signature로 구성되고 각각은 .으로 구분된다.
- Header에는 JWT에서 사용할 타입과 해시 알고리즘의 종류가 담긴다.
- Payload에는 서버에서 첨부한 사용자 권한 정보와 데이터가 담긴다.
- Signature에는 Header, Payload를 Base64 URL-safe Encode를 한 이후 Header에 명시된 해시함수를 적용하여 개인키(Private Key)로 서명한 전자서명이 담겨있다.
[참고될만한 링크]
[velopert][JWT] JSON Web Token 소개 및 구조
jwt.io
JWT 기반 인증 방식 (Access Token 기반 인증)
- 클라이언트가 로그인을 위해 해당 정보를 서버에 전달한다.
- 서버는 요청을 확인하고 로그인 성공 시
- Secret Key를 통해 Access Token을 발급한다.
- 발급된 JWT 토큰(Access Token)을 클라이언트에게 전달한다.
- 이후에 클라이언트에서 서버로 요청할 때 클라이언트가 Authorization header에 Access token을 담아서 보내면
- 서버는 JWT Signature를 체크하고 Payload로부터 사용자 정보를 확인해서 클라이언트의 요청에 대한 응답을 전달한다.
Access Token만을 통한 인증 방식의 문제점은 제 3자에게 토큰이 탈취될 경우 보안에 취약하다는 점이다.
Access Token은 발급된 이후, 서버에 저장되지 않고 토큰 자체로 검증을 하며 사용자 인증을 하기 때문에 토큰이 만료되기 전까지 토큰을 획득한 사람은 누구나 권한 접근이 가능하다.
또한, JWT 토큰은 발급한 후 삭제가 불가능하기 때문에 토큰에 유효기간을 부여하는 식으로 탈취 문제에 대해 대응을 해야 한다.
이러한 문제를 막기 위해 토큰의 수명이 짧은 Access Token과 Access token을 다시 발급 받기 위한 수명이 긴 Refresh Token을 발급하여 관리한다.
*Access Token과 Refresh Token은 이름이 다르긴해도 형태는 같은 JWT 토큰이다.
단지, Access Token은 접근에 관여하는 토큰이고, Refresh Token은 재발급에 관여하는 토큰으로 하는 역할만 다를 뿐이다.
- Refresh Token
- Access Token은 유효기간을 짧게 하여 지속적으로 반복되는 요청에 대해 빠르고 가볍게 처리할 수 있는 반면, Access Token이 만료된 경우 Refresh token을 이용해 다시 Access token을 발급받는다.
JWT 기반 인증 방식 (Refresh Token + Access Token 기반 인증)
- 클라이언트가 로그인을 위해 해당 정보를 서버에 전달한다.
- 이후에 클라이언트에서 서버로 요청할 때 Access Token만을 통한 토큰 방식처럼 서버로 Access Token을 보내게 되고,
- 서버는 Access Token을 검증해서
- 이에 맞는 응답을 클라이언트에게 보낸다.
- Access Token의 유효기간이 만료된 상태에서
- 클라이언트는 이전과 동일하게 Access Token로 서버 요청을 보내면
- 서버는 Access Token이 만료됨을 확인하고,
- 클라이언트에게
권한없음신호로 보낸다. - Access Toke 만료 신호(’권한 없음’) 신호를 받은 클라이언트는 Access Token과 Refresh Token을 서버에게 보내고,
- 서버는 Access Token이 조작되지 않았는지 확인한 후 Refresh Token과 서버의 회원 DB에 저장되어 있는 Refresh Token과 비교해서 토큰이 동일하다면 새로운 Access Token을 발급해서 Access Token을 헤더에 실어 클라이언트에게 응답을 보낸다.
Q> 그렇다면 세션과 토큰 중 어떤게 더 나은 선택인가?
A> 웹 사이트의 규모와 핸들링할 요청의 종류에 따라 선택할 수 있다.
유저의 로그인 세션 정도만 인증이 필요한 작은 웹사이트에서는 세션 인증이 보통 좋은 선택이 될 수 있다. 하지만 규모가 큰 웹 사이트라면 JWT가 훨씬 나은 선택이 될 수 있다.
JWT의 장단점
-
장점
- Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
- 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요없다. 즉, 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태가 된다.
- 수평 스케일이 용이하다.
- 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.
- OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
- 모바일 어플리케이션 환경에서도 잘 동작한다.
-
단점
- 쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 많은 필드가 추가되어 인증 요청이 많아질수록 네트워크 부하가 심해진다.
- Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
- 토큰을 탈취당하면 대처하기 어렵다.
- 토큰은 한 번 발급되면 유효기간이 만료될 때까지 계속 사용이 가능하기 때문이다.
- 특정 사용자의 접속을 강제로 만료하기 어렵지만, 쿠키/세션 기반 인증은 서버 쪽에서 쉽게 세션을 삭제할 수 있다.
[참고]
[WEB] 📚 JWT 토큰 인증 이란? - 💯 이해하기 쉽게 정리
[WEB] 📚 Access Token & Refresh Token 원리 (feat. JWT)
JWT (JSON Web Token) 이해하기와 활용 방안 - Opennaru, Inc.
네트워크 스터디 2주차 - 쿠키, 세션, 토큰, 캐시
https://sudo-minz.tistory.com/53
https://tansfil.tistory.com/59
https://surprisecomputer.tistory.com/36
https://pronist.dev/143
http://www.opennaru.com/opennaru-blog/jwt-json-web-token/
