세션 기반 로그인 vs 토큰 기반 로그인

세션 기반 로그인 vs 토큰 기반 로그인

유효한 사용자만 시스템 자원에 접근할 수 있도록 하는것을 접근 제어라고 합니다. 세션과 토큰에 관해 알아보기 전에 접근 제어의 개념에 대해 짚고 넘어가도록 하겠습니다.

 

인증과 인가

접근 제어는 인증(Authentication)과 인가 (Authorization)라는 두가지의 개념을 포함하는데 두 개념이 비슷해서 혼동하는 경우가 많습니다.

1. 인증

인증은 사용자가 본인이 맞는지를 검증하는 절차를 의미합니다. 예시로는 아이디와 비밀번호를 통해 로그인을 하는 과정이 있습니다.

 

2. 인가

인가는 인증된 사용자가 시스템 자원에 대한 접근 권한이 있는지 확인하는 절차를 의미합니다. 예시로는 게시글을 삭제하거나 수정할 때 작성자가 맞는지 확인하는 과정을 생각해보시면 됩니다.

 

세션과 토큰은 모두 사용자를 인증한 이후에 자원에 접근할 수 있는 권한을 담은 인가 정보를 어떤 방식으로 발급하고 저장할 것인가에 관한 방법입니다. 따라서 세션과 토큰은 인가에 관련된 기술이라고 볼 수 있습니다.

 

 

세션 기반 로그인

세션 기반 로그인은 사용자의 인가 정보가 서버의 세션 저장소에 저장되는 방식입니다. 사용자가 로그인을 하면, 서버는 해당 인가 정보를 세션 저장소에 저장한 후 세션 저장소의 식별자인 Session ID를 클라이언트 측에 전달합니다.

클라이언트 측은 전달받은 Session ID를 웹 스토리지 혹은 쿠키에 저장하고 인가가 필요한 요청시 함께 전달하게 됩니다.

 

세션 저장소로는 여러가지 방법을 사용할 수 있습니다.

 

참고 url: https://velog.io/@maestroks/Session-%EC%A0%80%EC%9E%A5%EC%86%8C%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-3%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95

Session 저장소를 사용하는 3가지 방법

 

 

토큰 기반 로그인

토큰 기반 로그인은 인가 정보를 서버가 추적하지 않고, 토큰만으로 권한을 판별하는 방식입니다. 사용자가 로그인을 하면, 서버는 인가 정보를 담은 Token을 발행한 후 클라이언트 측에 전달합니다. 클라이언트 측은 전달받은 Token을 웹 스토리지 혹은 쿠키에 저장합니다.

대표적인 토큰인 JWT의 경우 디지털 서명이 존재해 토큰의 내용이 위변조 되었는지 서버측에서 확인할 수 있습니다.

위변조 되지 않았고, 유효기간이 지나지 않았다면 유효한 사용자로 판단합니다.

 

참고 url: http://www.opennaru.com/opennaru-blog/jwt-json-web-token/

JWT (JSON Web Token) 이해하기와 활용 방안 - Opennaru, Inc.

 

 

세션과 토큰의 차이점

1. 사이즈

세션의 경우 세션 ID만 실어 보내면 되므로 트래픽을 적게 사용한다. 하지만 JWT는 사용자 인증 정보와 토큰의 발급시각, 만료시각, 토큰의 ID등 담겨있는 정보가 세션 ID에 비해 비대하므로 세션 방식보다 훨씬 더 많은 네트워크 트래픽을 사용한다.

Why JWTs Suck as Session Tokens 게시물에 따르면, 단순히 JWT에 iss, sub, nbf, exp, iat, jti, typ 클레임만을 실었는데 304 바이트가 나왔다고 한다. 그에 비해 세션 ID는 단 6바이트. 50배가 넘는 트래픽 비효율이다.

 

 

2. 안전성과 보안

세션의 경우 모든 인증 정보를 서버에서 관리하기 때문에 보안 측면에서 조금 더 유리하다. 설령 세션 ID가 해커에게 탈취된다고 하더라도, 서버측에서 해당 세션을 무효 처리하면 된다.

하지만 토큰의 경우 그렇지 않다. 토큰은 서버가 트래킹하지 않고, 클라이언트가 모든 인증정보를 가지고 있다. 따라서 토큰이 한번 해커에게 탈취되면 해당 토큰이 만료되기 전까지는 속수무책으로 피해를 입을 수 밖에 없다.

또한 JWT 특성상 토큰에 실린 Payload가 별도로 암호화 되어있지 않으므로, 누구나 내용을 확인할 수 있다. 따라서 Payload에 민감한 데이터는 실을 수 없다. 즉, Payload 에 실을 수 있는 데이터가 제한된다.

하지만 세션과 같은 경우에는 모든 데이터가 서버에 저장되기 때문에 아무나 함부로 열람할 수 없으므로 저장할 수 있는 데이터에 제한이 없다.

 

3. 확장성

그럼에도 불구하고 최근 모던 웹 어플리케이션이 토큰 기반 인증을 사용하는 이유가 바로 이 확장성이다.

일반적으로 웹 어플리케이션의 서버 확장 방식은 수평 확장을 사용한다. 즉, 한대가 아닌 여러대의 서버가 요청을 처리하게 된다. 이때 별도의 작업을 해주지 않는다면, 세션 기반 인증 방식은 세션 불일치 문제를 겪게 된다. 이를 해결하기 위해서 Sticky Session, Session Clustering, 세션 스토리지 외부 분리 등의 작업을 해주어야한다.

하지만, 토큰 기반 인증 방식의 경우 서버가 직접 인증 방식을 저장하지 않고, 클라이언트가 저장하는 방식을 취하기 때문에 이런 세션 불일치 문제로부터 자유롭다. 이런 특징으로 토큰 기반 인증 방식은 HTTP의 비상태성(Stateless)를 그대로 활용할 수 있고, 따라서 높은 확장성을 가질 수 있다.

 

4. 서버의 부담

확장성과 어느정도 이어지는 내용이다. 세션 기반 인증 방식은 서비스가 세션 데이터를 직접 저장하고, 관리한다. 따라서 세션 데이터의 양이 많아지면 많아질수록 서버의 부담이 증가할 것 이다.

하지만 토근 기반 인증 방식은 서버가 인증 데이터를 가지고 있는 대신, 클라이언트가 인증 데이터를 직접 가지고 있다. 따라서 유저의 수가 얼마나 되던 서버의 부담이 증가하지 않는다. 따라서 서버의 부담 측면에서는 세션 기반 인증 방식보다는 토큰 기반 인증 방식이 조금 더 유리함을 알 수 있다.

 

 

실제 사용 예

토큰 기반 로그인은 Access Token만 사용하는 것이 아니라 Refresh Token을 같이 사용하는 경우가 많습니다.

 

Token의 경우 탈취되었을 경우 대안이 없기 때문에 유효기간을 짧게 두는데, 이렇게 되면 사용자는 매번 로그인을 다시 해야하는 불편함이 발생한다.

이를 보완하기 위해 실제 시스템 자원 접근용의 Access Token과 Access Token을 다시 발급받기 위한 Refresh Token으로 토큰을 세분화 한 후,  Access Token은 짧은 유효기간을 갖도록 하고, Refresh Token은 긴 유효기간을 가지도록 설정하는 것이 일반적인 방법이다.

 

여기에 세션 방식을 섞어서 Refresh Token의 경우 세션 저장소에 저장하여 추가적인 이력관리 기능 혹은 원격 로그아웃 기능 등을 구현할 수 있도록 합니다.

다만 이런 방식의 경우 토큰 사용의 장점이 조금은 퇴색되는 단점이 있습니다.

 

참고 url: https://alexander96.tistory.com/52

리프레시 토큰 탈취 대응 전략을 고민하다 도달한 세션쿠키 vs 토큰에 대한 고민

 

---

 

참고 url:

https://hudi.blog/session-based-auth-vs-token-based-auth/