HTTP stateless 키워드

목표 D-day : 50 일

HTTP는 stateless 프로코톨로, 각 요청이 서로 독립적이며 서버는 클라이언트의 이전 요청을 기억하지 않습니다.

이 특징으로 클라이언트와 서버가 로그인 인증에 성공하고 인가를 위한 인증 유무를 어떻게 유지할지 학습합니다.

학습 키워드

• 인증
• 인가
• 세션
• 토큰
• 쿠키

인증

“누구인가?” 에 대한 확인 증명

인증(Authentication)은 사용자가 누구인지 증명하는 절차입니다.

클라이언트가 서버에 접속할 때, 자신의 신원을 확인하여 서버가 사용자를 식별하고 인증된 사용자임을 확인하는 과정입니다.

이 과정으로 사용자는 특정 리소스에 접근할 수 있는 자격이 있다는 것을 증명합니다.

인증 방식

• 아이디/비밀번호: 기본적인 인증 방식
• 소셜 로그인: 외부 인증 서비스

인가

“무엇을 할 수 있는가?”에 대한 확인

인가(Authorization)은 인증된 사용자가 서버의 특정 리소스나 기능에 대해 접근 권한을 가지고 있는지 확인하는 절차입니다.

인증된 사용자가 해당 리소스에 대해 어떤 작업을 할 수 있는지 결정하는 과정입니다.

인가는 주로 권한 레벨(Role)이나 권한 정책에 따라 달라집니다.

권한 레벨에 대해

1. 일반 사용자
2. 관리자
3. 관리자 매니저
4. 최상위 권한

과 같이 권한 레벨에 따라 리소스나 기능을 사용할 수 있는 제한이 되어있을 때 인가를 통해 결정할 수 있습니다.

HTTP와 Stateless

HTTP가 Stateless로 설계된 배경은 다음과 같습니다.

1. 정적 문서(HTML)를 주고 받기 때문에 클라이언트의 상태를 저장할 이유가 없습니다.

   초기 웹의 목적은 하이퍼텍스트 문서를 공유하고 전송하는 것이므로, 클라이언트의 상태 정보를 저장하거나 유지할 필요가 없었습니다.

2. 빠른 요청 처리와 단순한 설계가 가능하고 서버의 부담을 줄 일 수 있습니다.

   각 요청이 독립적이므로 빠르게 요청을 처리할 수 있고, 서버는 클라이언트의 상태를 기억하지 않기 때문에 단순한 설계와 서버 부담 감소의 장점이 있습니다.

쿠키, 세션, 토큰

HTTP의 Stateless로 클라이언트는 서버에 매번 접근할 때마다 인증을 받고 인가 과정이 필요합니다.

사용자가 처음 인증에 통과했다면 인증된 상태라는 것을 서버나 클라이언트에 저장하게 된다면 해결할 수 있습니다.

쿠키

쿠키는 서버가 클라이언트에게 전달한 작은 데이터 조각입니다.

클라이언트의 브라우저에 저장되어 이후 서버와의 요청에서 반복적으로 사용됩니다. 주로 세션 ID, 사용자 설정, 로그인 상태등을 유지하는데 사용됩니다.

장점

서버의 상태를 저장할 필요 없이 상태를 유지할 수 있고, 클라이언트 측에서 설정이나 인증 정보를 관리할 수 있습니다.

단점

사용자가 쿠키를 변조할 수 있고, 보안에 취약하기 때문에 민감한 개인 정보를 저장하는 데는 적합하지 않습니다. 이를 방지하기 위해서 HttpOnly,Secure,SameSite와 같은 보안 속성을 설정하여 보안을 높일 수 있습니다.

쿠키는 데이터를 전달한 서버의 도메인이 동일한 경우에만 전송합니다.

세션

세션은 사용자가 서버에 인증을 통과한 이후, 사용자의 인증 상태를 서버 측에서 관리하고 유지하는 방식입니다.

사용자가 로그인에 성공하면 서버는 세션을 생성하고, 세션은 서버 메모리나 세션 저장소에 저장됩니다.

서버는 쿠키에 세션ID를 클라이언트에 전달하여 인증 상태를 유지합니다.

인가 과정에서 클라이언트가 전달한 세션 ID를 서버에서 조회하여 유효 여부를 확인하는 과정이 생깁니다.

장점

1. 상태 관리가 편합니다: 서버가 사용자의 인증 상태를 직접 관리하므로, 중복 로그인 방지, 사용자의 로그아웃, 인증 만료 등을 쉽게 제어할 수 있습니다.
2. 보안성: 세션은 서버 측에서 관리되므로 민감한 정보를 클라이언트 측이 보관하지 않으므로 안전하게 관리할 수 있습니다.
3. 유효 기간 제어: 세션의 유효 기간은 서버에서 설정하며, 쿠키에 비해 더 긴 유효기간을 설정할 수 있습니다.

단점

1. 서버 리소스 소모: 사용자가 많아질 수록 사용자 인증 상태를 관리하기 위한 메모리 사용량이 증가하여 서버에 부담이 됩니다.

   특히 사용자가 동시에 접속하는 경우 세션 관리를 위한 리소스가 크게 증가합니다.

2. 서버 장애시 세션 손실: 서버가 재시작하거나 장애가 발생한다면, 메모리에 저장된 세션 정보도 같이 사라집니다.

3. 서버 확장 문제: 서버가 여러 대일 경우, 각 서버마다 다른 세션 정보가 저장되므로 로드 밸런싱을 통해 요청이 다른 서버로 분배된다면, 동일한 세션 상태를 유지하기 어렵습니다.

해결방안

• 세션 저장소 사용 : Redis와 같은 인메모리 DB를 사용하여 세션을 저장하면, 분산된 서버 환경에서도 세션 정보를 동일한 세션 저장소에서 참조할 수 있습니다. 서버가 여러 대 일지라도 일관된 세션 상태를 유지할 수 있습니다.
• 공용 데이터 베이스 : RDBMS와 같은 공용 데이터베이스에 세션 정보를 저장하여 인증 상태를 공유할 수 있습니다. 다만, 인메모리 DB에 비해 느리고, 실시간 처리가 많은 경우 성능이 떨어 질 수 있습니다.

토큰

토큰은 세션과 달리 인증 상태를 클라이언트 측에서 암호화 하는 방식입니다.

사용자가 로그인에 성공하면 서버는 JWT와 같은 토큰을 클라이언트에 전달하고, 토큰에는 사용자 인증 상태, 권한 정보 등이 암호화된 형태로 포함되어 있습니다.

쿠키와 유사하게 클라이언트가 상태를 저장하므로 서버의 부담을 줄이고 확장하는데 적합합니다.

장점

• 서버의 상태를 유지하지 않음: 서버가 인증 상태를 저장하지 않으므로 서버의 부담을 줄이고, 확장하기 편합니다.

• 여러 서버가 있는 환경에 유리: 서버마다 토큰을 검증하므로 별도의 세션 DB가 필요없습니다.

단점

• 인증 상태 제어의 어려움: 사용자의 인증 상태를 클라이언트에서 관리하므로 서버가 직접 로그아웃하거나 토큰 무효화를 바로 적용하는 것은 어렵습니다.
• 보안 취약성: 토큰이 노출되면 해커가 이 토큰을 사용해 요청을 보내면 인증된 사용자로 리소스에 접근할 수 있습니다.

해결방안

한번 발행된 토큰은 유효 기간 동안 서버에서 제어할 수 없습니다.

토큰의 유효 기간을 최대한 줄이고, 토큰을 재발행 할 수 있는 Refresh 토큰을 사용하여 토큰이 노출되더라도 위험의 최소화 할 수 있습니다.

기존 토큰 방식에서 사용하는 토큰은 access token으로 인증 상태를 가진 토큰을 말합니다.

여기에 access token을 재발행 할 수 있는 refresh token을 추가로 발행하고 서버는 리프레시 토큰을 저장합니다.

access token의 유효 기간을 최소로 만들고, 유효기간이 종료되면 refresh token으로 access token을 재발행 합니다.

클라이언트가 전달한 refresh token과 서버에서 저장한 refresh token이 동일해야 발행이 가능하며

로그아웃시 Refresh token을 삭제하여 사용자를 강제 로그아웃 처리하는 방식을 사용할 수 있습니다.