Security JWT,세션, 쿠키방식

스프링 Security 동작방식

  사용자 인증은 시스템이나 애플리케이션에 접근하려는 사용자가 실제로 그 사용자가 맞는지 확인하는 과정이다.  사용자 경험과 확장성도 고려해야 한다. 이미 사용자 인증을 마친 회원이 페이지를 이동할 때마다 사용자 인증을 하게 된다면 사용자에게는 굉장히 불편한 서비스가 될 것이며, 서비스가 성장함에 따라 확장에 유연하지 못하다면, 확장 비용을 무시할 수 없게 된다. 따라서, 사용자 인증 방식들을 보안성, 사용자 경험, 확장성을 중심으로 비교해 보고 선택하는 것이 중요하다.

 

  Security 관리방식은 크게 두가지 방식으로 나뉜다. Stateless이냐 혹은 Session-Based이냐.

  Stateless는 서버가 클라이언트의 이전 상태를 기억하지 않는 방식으로, 매 요청마다 JWT를 통해 인증이 이루어진다. 

• 토큰 인증 방식은 DB를 거치지 않고 오로지 토큰만을 사용하여 인증하기 때문에 응답속도 저하 문제를 해결할 수 있으며,
• 확장성면에서도 확실히 우수한 면을 보인다.
• 반면, 토큰 인증 방식의 단점이라면, 토큰 탈취시 세션과 달리 서버에서 무효화하기 어려워 위험이 있다는 것.

  반면 Session-Based는 JWT Authentification을 거친 후, https 헤더의 세션 항목에 SecurityContext에 대한 정보가 암호화되어 저장되어 JWT auth를 여러번 할 필요가 없다. Session-Based는 서버가 클라이언트의 상태를 유지하는 방식으로, 최초 인증 후 세션 정보를 서버에 저장한다. 

• 클라이언트는 세션 ID를 이용해 이후 요청에서 인증 과정을 간소화하며, 서버는 세션 정보를 바탕으로SecurityContext를 유지한다.
• 하지만 빈번히 발생하는 사용자의 요청마다 DB에 접근한다는 것은 응답 속도 저하를 일으키는 원인이 되며, 이러한 요청이 수백, 수천만 건이 된다면 서버에 부하를 일으키는 원인까지 될 수 있다.
• 또한, 요즘은 금융권도 MSA를 도입할 만큼 분산 환경을 자주 볼 수 있는데, 이런 환경에서 세션의 일관성을 유지하기 위해 중앙 저장소를 사용하거나 추가적인 작업을 해야 한다는 점은 세션 인증 방식의 확장성 면에서 큰 단점으로 꼽힐 수 있다.

 

1. Stateless JWT-Based Authentication:

Concept:

• JWT 토큰 발급: 사용자가 인증에 성공하면, 서버는 사용자 인증 정보를 포함하는 JWT(JSON Web Token)를 생성합니다. 이 토큰에는 사용자 ID, 역할(roles) 등의 정보가 포함되며, 서버에서 서명하여 무결성을 보장합니다.
• 서버 상태 저장 없음 : 세션 기반 인증과 달리, 서버는 별도의 세션 데이터를 저장하지 않습니다. 필요한 모든 정보는 JWT 내부에 인코딩되어 있습니다.
• 무상태성 : 서버는 인증에 관해 상태를 유지하지 않으며, 요청마다 독립적으로 JWT를 통해 인증합니다.

Pros:

• 확장성 : 서버가 세션을 저장하거나 관리할 필요가 없으므로, JWT 기반 인증은 높은 확장성을 제공합니다. 이는 분산 시스템이나 마이크로서비스 아키텍처에 이상적입니다.
• 탈중앙화 : JWT는 중앙 집중식 세션 저장소가 필요하지 않아, 서로 다른 도메인이나 서비스 간에 쉽게 사용할 수 있습니다. 이는 API 인증과 마이크로서비스 간 인증 공유에 유용합니다.

Cons:

•  보안 문제 : JWT는 일반적으로 수명이 길며, 발급된 후 만료될 때까지 유효합니다. JWT가 유출되면, 만료 전까지 공격자가 이를 악용할 수 있습니다. 이를 방지하려면 토큰 블랙리스트와 같은 추가적인 메커니즘이 필요합니다. 
• 토큰 폐기 어려움 :세션은 서버에서 쉽게 무효화할 수 있지만, JWT는 만료 전에 폐기하기가 복잡합니다. 이를 해결하려면 별도의 인프라(예: 블랙리스트 저장소)가 필요합니다. 토큰을 즉시 무효화하기 어렵기 때문에 Refresh Token 전략과 블랙리스트 관리가 필수.
  • 짧은 만료 시간 설정: Access Token(JWT)은 짧은 만료 시간을 설정하고, 별도의 Refresh Token을 통해 만료된 JWT를 갱신합니다. Refresh Token은 서버에서 관리되므로, 유출된 Access Token을 갱신하지 못하게 할 수 있습니다. 
  • HTTPS, Secure Storage 등 보안 기본 원칙 준수.

•  토큰 크기:JWT는 세션 ID보다 크기가 큰 경우가 많습니다. 이는 정보량이 많기 때문이며, 작은 빈번한 요청이 많은 경우 요청마다 전송되는 데이터 양이 늘어나 부담이 될 수 있습니다.

 

1.2 Access Token과 Refresh Token의 관계와 작동 방식

JWT 기반 인증 시스템에서 Access Token과 Refresh Token은 보안성과 편의성을 동시에 제공하기 위해 사용됩니다. 

 

Access Token : 사용자가 API에 요청을 보낼 때 인증을 위해 사용됩니다.

• 만료 시간: 짧게 설정(예: 15분 ~ 1시간). 짧은 만료 시간은 토큰이 유출되더라도 공격자가 사용할 수 있는 시간을 제한합니다.

Refresh Token : Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용됩니다.

• 보관: 서버에서만 저장하거나, 클라이언트가 보관하더라도 보안이 강화된 방식(예: Secure Cookie)을 사용해야 합니다.
• 만료 시간: 길게 설정(예: 며칠 ~ 몇 주).

 

1.3 세션(Session) 방식

• 서버가 사용자 상태를 서버 메모리에 저장.
• 사용자는 로그인 후, 서버에서 생성된 고유한 세션 ID를 발급받아 브라우저 쿠키에 저장이후 클라이언트는 요청마다 세션 ID를 포함하여 서버에 보냄.
• 서버는 해당 세션 ID를 기준으로 사용자 정보를 조회하고 인증 여부를 확인.

장점

1. 보안성: 사용자 정보가 서버에 저장되므로, 세션 정보 자체가 클라이언트에 노출되지 않음.
2. 복잡한 인증 상태 관리 가능: 서버에서 세션 정보를 자유롭게 업데이트 가능. 예: 권한 변경, 사용자 로그아웃 처리 등.

단점

1. 서버 메모리 의존: 모든 사용자 세션을 서버에서 관리하므로, 사용자 수가 많아질수록 서버 자원 소모 증가. 클러스터 환경에서는 세션 동기화가 필요.
2. 스케일링 어려움: 다중 서버 환경에서 세션 정보를 공유하거나 Redis 같은 외부 스토리지를 사용해야 함.

1.4 쿠키(Cookie) 방식

• 클라이언트 쪽에 사용자 상태를 저장.
• 서버는 클라이언트에 특정 키-값 형태의 데이터를 포함한 쿠키를 발급하고, 클라이언트는 요청마다 이 쿠키를 서버로 전송.
• 쿠키에 중요한 정보(예: 사용자 ID)를 담을 수 있지만, 일반적으로 민감한 데이터는 저장하지 않음.

장점

1. 서버 부담 감소 : 사용자 상태를 클라이언트가 관리하므로, 서버의 메모리 자원이 절약됨.
2. 구현 간단 : 별도의 서버 상태 관리가 필요 없으므로 간단히 사용할 수 있음.

단점

1. 보안 취약 : 클라이언트에 저장된 쿠키가 탈취될 가능성이 있음. 중요한 데이터를 저장하려면 반드시 암호화 필요.
2. 데이터 크기 제한 : 쿠키의 크기가 브라우저마다 제한됨(일반적으로 4KB).