서버 기반 인증 시스템
출처 : https://mangkyu.tistory.com/55
세션 기반 인증
기존의 인증 시스템은 서버 기반의 인증 방식으로, 서버측에서 사용자들의 정보를 기억하고 있어야한다. 사용자들의 정보를 기억하기 위해선 세션을 유지해야 하는데, 메모리나 디스크 또는 데이터베이스 등을 통해 관리한다.
서버 기반의 인증 시스템은 클라이언트로부터 요청을 받으면, 클라이언트의 상태를 계속해서 유지하고 이 정보를 서비스에 이용한다. 이런 서버를 Stateful 서버라고 한다.
이러한 인증 방식은 소규모 시스템에서는 아직 많이 사용되지만, 웹/앱 애플리케이션이 발달하게 되면서 서버를 확장하기 어렵다는 문제점 발생
세션
사용자 인증을 할 때, 서버는 이를 저장해야하고, 이를 세션이라고 부름. 대부분의 경우는 서버의 메모리에 저장하기 때문에 서버 RAM에 부하가 걸린다. 이를 피하려고 DB에 저장하기도 하는데, 이는 마찬가지로 DB에 무리를 줄 수 있음.
확장성
사용자가 늘어나게 되면 더 많은 트래픽을 처리하기 위해 여러 프로세스를 돌리거나 컴퓨터를 추가하는 등 서버를 확장해야함. 세션을 사용한다면 세션을 분산시키는 시스템을 설계해야하지만 이러한 과정은 매우 어렵고 복잡
CORS(Cross Origin Resource Sharing)
웹 애플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어있음. 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거로움
이러한 문제들 때문에 토큰 기반 인증 시스템을 사용하게됨
토큰 기반 인증 (JWT)
인증받은 사용자들에게 토큰을 발급하고, 서버에 리소스를 요청할 때 헤더에 토큰을 함께 보내도록 하여 유효성 검사를 하는 방식
더이상 사용자의 인증정보를 서버나 세션에 저장하지 않고 클라이언트 측에서 들어오는 요청만으로 작업을 처리. 즉, 서버 기반의 인증 시스템과 달리 상태를 유지하지 않으므로 Stateless한 구조를 갖는다. 이러한 토큰 기반 인증 방식을 통해 수많은 문제점들을 해결할 수 있는데, 대표적으로 사용자가 로그인이 되어있는지 안되어있는지 확인하지 않고 손쉽게 시스템 확장 가능
토큰 기반 인증 동작 과정
- 사용자가 아이디 비밀번호로 로그인
- 서버측에서는 해당 정보 검증(인증)
- 인증이 되면 서버측에서 서버에게 Signed 토큰을 발급 (Signed는 해당 토큰이 서버에서 정상적으로 발급되었음을 증명하는 Signature를 가지고 있는 것)
- 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청할 때마다 해당 토큰을 서버에 함께 전달. 이때 Http 요청 헤더에 토큰을 포함
- 서버는 토큰을 검증하고, 요청에 응답.
토큰 기반 인증 시스템 이점
무상태성(Stateless) & 확장성(Scalability)
토큰을 클라이언트 측에 저장되기 때문에 서버는 완전히 Stateless하며, 클라이언트와 서버의 연결고리가 없기 때문에 확장하기 매우 적합.
만약 사용자 정보가 서버측 세션에 저장된 경우 서버를 확장하여 분산처리 한다면, 해당 사용자는 처음 로그인 했었던 서버에만 요청을 받도록 설정을 하거나, 세션 클러스터링이나 세션 서버를 따로 구성해야한다. 하지만, 토큰을 사용한다면 어떠한 서버로 요청이 와도 상관없다.
보안성
클라이언트가 서버로 요청을 보낼 때 더이상 쿠키를 전달하지 않으므로, 쿠키사용에 의한 취약점이 사라진다. 하지만 토큰을 탈취당할 수도 있으니 이에 대비해야한다.
확장성(Extensibility)
시스템의 확장성을 의미하는 Scalability와 달리 Extensibility는 로그인 정보가 사용되는 분야의 확장을 의미한다. 토큰 기반의 인증 시스템에서는 토큰에 선택적인 권한만 부여하여 발급할 수도 있으며, OAuth의 경우 Facebook, Google과 같은 소셜계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
여러 플랫폼 및 도메인
서버 기반 인증 시스템의 문제점인 CORS를 해결할 수 있다. 애플리케이션과 서비스의 규모가 커지면 여러 디바이스를 호환시키고 더 많은 종류의 서비스를 제공하게 된다. 토큰을 사용한다면 어떤 디바이스, 어떤 도메인에서도 토큰의 유효성 검사를 진행한 후에 요청을 처리할 수 있다.
이런 구조를 통해 assests파일 (Image, html, css, js등)은 모두 CDN에서 제공하고, 서버 측에서는 API 만 다루도록 설계할 수 있다.
JWT (JSON Web Token)
JWT는 토큰 자체를 정보로 사용하는 Self Contained방식으로 정보를 안전하게 전달
JWT 구조
Header, Payload, Signature로 구성
Header
- typ과 alg 두가지 정보로 구성
- alg는 헤더를 암호화하는 것이 아니고, Signature를 해싱하기 위한 알고리즘 지정, 알고리즘 방식을 지정하며 서명(Signature) 및 토큰 검증에 사용 ex) H2256(SHA256) 또는 RSA
- typ는 토큰의 타입을 지정 ex) JWT
Payload
토큰의 페이로드에는 토큰에서 사용할 정보의 조각들인 Claim이 담겨잇다. 클레임은 총 3가지로 나누어지면, JSON(Key, Value) 형태로 다수의 정보를 넣을 수 있다.
- 등록된 클레임
- 공개 클레임
- 비공개 클레임
Signature(서명)
토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드이다.
서명은 위에서 만든 헤더와 페이로드의 값을 각각 BASE64로 인코딩하고, 인코딩한 값을 비밀키를 이용해 헤더에서 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 BASE64로 인코딩하여 서명을 생성한다.
JWT 단점 및 고려사항
- Self-Contained : 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다.
- 토큰 길이 : 토큰의 페이로드에 3종류의 클레임을 저장하기 때문에, 정보가 많아질 수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다.
- payload 인코딩 : 페이로드 자체는 암호화된 것이 아니라 BASE64로 인코딩 된 것이다. 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로 JWE로 암호화하거나 Payload에 중요한 데이터를 넣지 않아야한다.
- Stateless : JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능하다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료시간을 꼭 넣어주어야한다.
- Tore Token : 토큰은 클라이언트 측에서 관리해야하기 때문에, 토큰을 저장해야한다.
