REST API 서비스와 Stateless 아키텍처

REST API

REST에 대하여 참고

Stateful vs Stateless

Stateful 아키텍처의 장단점

• Session을 사용하고 있으면, Stateful 하다고 할 수 있다.
• 앞서 살펴본 것처럼 수평확장(Scale-Out) 과정이 쉽지 않다.
  • Session Cluster 반드시 필요하다.
• 단일 사용자의 다중 로그인 컨트롤, 사용자 유효성 체크, 강제 로그아웃 기능 구현이 쉽다.

Stateless 아키텍처의 장단점

• Session을 전혀 사용하지 않아야 한다.
• 수평확장이 매우 쉽다.
• 단일 사용자의 다중 로그인 컨트롤, 사용자 유효성 체크, 강제 로그아웃 기능 구현이 어렵다.
  • 완전한 Stateless 아키텍처 기반으로 유의미한 서비스 개발이 어렵다.
    완전한 Stateless 서비스는 정적 리소스(html, css, javascript, 이미지 등)를 서비스 하는데 적합하다.
• 서버는 session을 사용하지 않고 어떤식으로는 사용자를 식별할 수 있어야 한다.

JWT

JWT는 Stateless 상태를 유지하며, 서버에서 사용자를 식별할 수 있는 수단을 제공한다.

• 서버에서 사용자가 성공적으로 인증되면 JWT를 반환한다.
• 클라이언트는 JWT를 로컬 영역에 저장하고, 이후 서버에 요청을 보낼 때 JWT를 HTTP 헤더에 포함시킨다.
• 서버는 클라이언트가 전달한 JWT를 통해 사용자를 식별할 수 있다.

구조

Header

JWT를 검증하는데 필요한 정보를 담고 있다. (토큰 타입, 사용된 알고리즘)

Payload

Reserved Claims, Public Claims, Custom Claims 으로 구분된다.

Reserved Claims

미리 등록된 Claims 필수적으로 사용할 필요는 없지만 사용을 권고한다.

• iss: 토큰을 발급한 발급자 (Issuer)
• exp: 만료시간이 지난 토큰은 사용불가
• nbf: Not Before의 의미로 해당 시간 이전에는 토큰 사용불가
• iat: 토큰이 발급된 시각
• jti: JWT ID로 토큰에 대한 식별자

Public Claims

사용자 마음대로 쓸 수 있으나 충돌 방지를 위해 미리 정의된 이름으로 사용을 권고한다.

Custom Claims

사용자 정의 Claim으로 Reserved, Public 에 정의된 이름과 중복되지 않도록한다.

Signature

• 토큰 생성 주체만 알고 있는 비밀키를 이용해 헤더에 정의된 알고리즘으로 서명된 값
• 토큰이 위변조 되지 않았음을 증명한다.
  • key의 경우 서버에서만 알고 있기에 서명 데이터를 올바르게 생성할 수 없다. 그리고 이러한 점을 통해 JWT를 확인할 수 있다.

장단점

장점

• 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 따로 스토리지가 필요 없다.
  • Active User가 많은 서비스에서 JWT사용이 유리함

단점

• 토큰 크기를 가능한 작게 유지해야 한다.
• 유효기간이 남아 있는 정상적인 토큰에 대해 강제적으로 만료 처리가 어렵다.

참고

JWT에 대하여 참고

필터 설정

.headers()

• Security header 설정을 할 수 있다.
• Security header에 대하여 참고
  

.httpBasic()

• HTTP 기본 인증에 대한 설정을 할 수 있다.