JWT와 현대 웹 인증 아키텍처 - Stateless 인증: JWT와 현대 인증 구조 웹 애플리케이션의 인증 방식은 웹 아키텍처의 변화와 함께 지속적으로 발전해 왔습니다. 초기 웹에서는 HTTP의 Stateless 특성 때문에 사용자 상태를 유지하기 어려웠고, 이를 보완하기 위해 Cookie가 등장했습니다. 이후 보안성과 관리 측면에서 개선된 방식으로 Server Session 기반 인증 구조가 널리 사용되었습니다. 그러나 웹 서비스 규모가 커지고 시스템 구조가 점점 분산되면서 Session 기반 인증 방식 역시 여러 한계를 드러내기 시작했습니다. 특히 API 중심 아키텍처와 MSA 환경에서는 서버가 사용자 상태를 직접 저장하는 방식이 확장성 측면에서 부담이 되는 경우가 많았습니다. 이러한 흐름 속에서 ..
서버가 로그인 상태를 기억하는 방법Session 기반 인증의 등장 웹 애플리케이션에서 로그인, 장바구니, 사용자 개인화 같은 기능을 제공하려면 사용자의 상태를 어느 정도 유지해야 합니다. 하지만 HTTP는 기본적으로 Stateless 프로토콜로 설계되어 있기 때문에 서버는 기본적으로 이전 요청의 상태를 기억하지 않습니다. 이 문제를 해결하기 위해 웹에서는 다양한 상태 관리 방식이 등장했습니다. 이전 글에서는 HTTP의 Stateless 특성과 함께 Cookie가 등장하게 된 배경을 정리했습니다. Cookie는 클라이언트에 작은 데이터를 저장하고 이후 요청마다 서버로 전달하는 방식으로 상태를 유지하려는 시도였습니다. 그러나 Cookie에 인증 정보를 직접 저장하는 방식은 여러 보안 문제를 만들 수 있었습니..
HTTP는 왜 Stateless로 설계되었을까웹의 상태 관리가 시작된 이유 오늘날의 웹 애플리케이션은 로그인, 장바구니, 사용자 개인화 같은 다양한 기능을 자연스럽게 제공합니다. 그러나 웹이 처음 등장했을 당시에는 이러한 기능을 전혀 고려하지 않은 단순한 구조였습니다. 초기 웹은 문서를 전달하는 시스템에 가까웠으며, 오늘날 우리가 사용하는 서비스형 애플리케이션과는 성격이 상당히 달랐습니다. 이러한 차이를 이해하려면 먼저 HTTP 프로토콜의 설계 철학을 살펴볼 필요가 있습니다. HTTP는 기본적으로 Stateless 프로토콜로 설계되었습니다. 이 설계는 초기 인터넷 환경과 웹의 사용 목적을 고려하면 상당히 합리적인 선택이었습니다. 하지만 웹이 점점 애플리케이션 형태로 발전하면서 상황이 달라졌습니다. 사용자..
- Total
- Today
- Yesterday
- 백엔드 성능 설계
- Spring Batch
- Enum 기반 싱글톤
- 캐시 성능 비교
- 동시성처리
- DB 인덱스 성능
- 백엔드 아키텍처
- 스레드 생명주기
- Cache Avalanche
- 캐시와 인덱스
- 트랜잭션 관리
- Initialization-on-Demand Holder Idiom
- 백엔드 성능
- Redis 캐시 전략
- Hot Key 문제
- Double-Checked Locking
- Java Performance
- DB 트랜잭션
- 백엔드 성능 튜닝
- InterruptedException
- mybatis
- Redis 성능 개선
- Cache Penetration
- spring batch 5
- 캐시 장애
- Eager Initialization
- Cache Aside
- 트래픽 처리
- TTL 설계
- Redis vs DB
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |

