Section 4 JWT(JSON Web Token) (1)

챠오·2023년 1월 18일
0

코드스테이츠

목록 보기
5/7

토큰 기반 자격 증명

HTTP 프로토콜은 request를 전송한 후, response를 수신하게 되면 연결을 끊는 비연결성(Connectionless)의 특성을 가지고 있고 또한 request와 response에 대한 상태를 저장하지 않는 비상태성(Stateless)의 특성을 가지고 있기 때문에 로그인 인증이 성공적으로 수행되었다 하더라도 서버 측에서는 매 번 request를 수신할 때 마다 이 request가 인증된 사용자가 보낸 request인지 알 수 있는 방법이 없다.

이러한 HTTP 특성으로 인해 사용자의 인증이 성공적으로 이루어졌을 때, 인증된 사용자 request의 상태를 유지하기 위한 수단이 필요하게 되었으며 대표적인 수단이 바로 세션이다.


세션 기반 자격 증명 방식

세션 기반 자격 증명 방식은 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장 하는 방식이다.

즉, 클라이언트 측에서 서버 측의 리소스를 요청하면 서버 측에서는 "서버 측 리소스를 요청하는 클라이언트에게 우리가 정보를 줘도 괜찮은가?"를 확인하기 위해 서버 측 세션 저장소에 저장된 세션 정보와 사용자가 제공하는 정보가 일치하는지 확인하는 방식이라고 할 수 있다.


세션 기반 자격 증명의 특징

세션은 인증된 사용자 정보를 서버 측 세션 저장소에서 관리한다.

생성된 사용자 세션의 고유 ID인 세션 ID는 클라이언트의 쿠키에 저장되어 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.

  • 세션 ID만 클라이언트 쪽에서 사용하므로 상대적으로 적은 네트워크 트래픽을 사용한다.

  • 서버 측에서 세션 정보를 관리하므로 보안성 측면에서 조금 더 유리하다.

  • 서버의 확장성 면에서는 세션 불일치 문제가 발생할 가능성이 높다.

  • 세션 데이터가 많아질수록 서버의 부담이 가중될 수 있다.

  • SSR(Server Side Rendering) 방식의 애플리케이션에 적합한 방식이다.

  • 세션 기반의 자격 증명 방식은 인증된 사용자의 상태를 유지하기 위한 전통적인 방식이다.
  • 그런데 세션 방식 이 외에 현대적인 웹 애플리케이션에서 점차 많이 사용되고 있는 방식이 있는데 그것이 바로 토큰 기반의 자격 증명 방식이다.

토큰 기반 자격 증명 방식

토큰이라 하면 흔히 아래의 경우를 떠올린다.

  • 대중교통을 이용할 때 사용하는 토큰

  • 오락실 게임에 사용하는 토큰

  • 행사에 입장하기 위해서 주최 측에서 나누어 준 토큰

  • 놀이공원에 입장료를 내면 주는 토큰

위 토큰들은 공통적으로 '나는 돈을 지불했고, 이 시설(혹은 서비스)을 사용할 수 있어!' 라는 메시지를 담고 있다.

일상 생활에서의 이러한 개념에 더해 애플리케이션 보안 측면에서의 토큰은 일종의 출입 카드에 비교될 수 있다.

여러분들이 특정 빌딩을 방문했을 때, 1층 로비 안내 데스크에서 임시 출입 카드를 발급해주는 상황을 상상해 보세요.

예를 들어 한 회사를 방문한다고 가정해보자.

안내 데스크 직원의 요청에 따라서 방문자 목록에 신원 정보(이름, 전화 번호, 방문 회사, 방문 목적 등)를 입력하고, 임시 출입 카드를 건네 받게 될 것이다.

여기서의 신원 정보는 자신을 증명하는 자격 증명 정보(Credential)에 비유될 수 있고, 임시 출입 카드는 인증된 자신을 증명하는 토큰에 비유될 수 있다.

그런데 발급 받은 임시 출입 카드로 빌딩 내에 있는 모든 장소의 출입문을 열 수 있을까? 아마도 방문하는 층의 특정 사무실에만 출입이 가능할 것이다.

이처럼 애플리케이션에서 사용되는 토큰 역시 인증된 사용자의 자격을 증명하는 동시에 접근 권한을 부여해 접근 권한이 부여된 특정 리소스에만 접근이 가능하게 하는 역할을 한다.

애플리케이션 보안 측면에서의 토큰에 대해서 대략적인 개념을 이해했을테니 토큰을 사용한 인증 방식은 어떠한 특징을 가지고 있는지 확인해 보자.

✅ 토큰 기반 자격 증명의 특징

  • 토큰에 포함된 인증된 사용자 정보는 서버 측에서 별도의 관리를 하지 않는다.

  • 생성된 토큰을 헤더에 포함시켜 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.

  • 토큰내에 인증된 사용자 정보 등을 포함하고 있으므로 세션에 비해 상대적으로 많은 네트워크 트래픽을 사용된다.

  • 기본적으로 서버 측에서 토큰을 관리하지 않으므로 보안성 측면에서 조금 더 불리하다.

  • 인증된 사용자 request의 상태를 유지할 필요가 없기 때문에 서버의 확장성 면에서 유리하고, 세션 불일치 같은 문제가 발생하지 않는다.

  • 토큰에 포함되는 사용자 정보는 토큰의 특성상 암호화가 되지 않기때문에 공격자에게 토큰이 탈취될 경우, 사용자 정보를 그대로 제공하는 셈이된다. 따라서 민감한 정보는 토큰에 포함시키지 말아야 한다.

  • 기본적으로 토큰이 만료되기 전까지는 토큰을 무효화 시킬 수 없다.

  • CSR(Client Side Rendering) 방식의 애플리케이션에 적합한 방식이다.

세션의 경우 서버 확장 시, 세션 불일치 문제가 발생할 수 있지만 Sticky Session, Session Clustering, Session 저장소의 외부 분리 등의 작업을 통해 보완을 하고 있다.

그리고 토큰의 경우, 기본적으로 토큰 무효화를 할 수 없지만 key/value 쌍의 형태로 저장되는 Redis 같은 인메모리 DB에 무효화 시키고자 하는 토큰의 만료 시간을 짧게 주어 해당 토큰을 사용하지 못하게 하는 등의 방법을 사용해 토큰 무효화 문제를 보완하고 있다.


핵심 포인트

  • 세션 기반 자격 증명 방식은 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장 하는 방식이다.

  • 세션 기반 자격 증명의 특징

  • 세션은 인증된 사용자 정보를 서버 측 세션 저장소에서 관리한다.

  • 생성된 사용자 세션의 고유 ID인 세션 ID는 클라이언트의 쿠키에 저장되어 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.

  • 세션 ID만 클라이언트 쪽에서 사용하므로 상대적으로 적은 네트워크 트래픽을 사용한다.

  • 서버 측에서 세션 정보를 관리하므로 보안성 측면에서 조금 더 유리하다.

  • 서버의 확장성 면에서는 세션 불일치 문제가 발생할 가능성이 높다.

  • 세션 데이터가 많아지면 질수록 서버의 부담이 가중될 수 있다.

  • SSR(Server Side Rendering) 방식의 애플리케이션에 적합한 방식이다.

  • 토큰 기반 자격 증명 방식은 인증된 사용자의 정보를 토큰에 저장하고, 접근 권한을 부여해 접근 권한이 부여된 특정 리소스에만 접근이 가능하게 하는 방식이다.


토큰 기반 자격 증명의 특징

  • 토큰에 포함된 인증된 사용자 정보는 서버 측에서 별도의 관리를 하지 않는다.

  • 생성된 토큰을 헤더에 포함시켜 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.

  • 토큰내에 인증된 사용자 정보 등을 포함하고 있으므로 세션에 비해 상대적으로 많은 네트워크 트래픽을 사용한다.

  • 기본적으로 서버 측에서 토큰을 관리하지 않으므로 보안성 측면에서 조금 더 불리하다.

  • 인증된 사용자 request의 상태를 유지할 필요가 없기 때문에 서버의 확장성 면에서 유리하고, 세션 불일치 같은 문제가 발생하지 않는다.

  • 토큰에 포함되는 사용자 정보는 토큰의 특성상 암호화가 되지 않기때문에 공격자에게 토큰이 탈취될 경우, 사용자 정보를 그대로 제공하는 셈이 되므로 민감한 정보는 토큰에 포함시키지 말아야 한다.

  • 기본적으로 토큰이 만료되기 전까지는 토큰을 무효화 시킬 수 없다.

  • CSR(Client Side Rendering) 방식의 애플리케이션에 적합한 방식이다.

profile
무용한 헛소리들

0개의 댓글