| Session | JWT |
| 세션 정보를 저장하기 위한 별도의 저장소가 필요합니다. | 별도의 저장소가 필요하지 않습니다. |
| 세션 무효화가 쉽습니다. | JWT 무효화가 쉽지 않습니다. |
| 확장 시 세션 저장소도 고려해야 합니다. | 클라이언트와 서버의 확장이 쉽습니다. |
1. 세션 기반 인증
1. 사용자는 로그인 사용자 인증 정보를 서버로 보냅니다.
2. 서버는 이러한 자격 증명을 확인합니다.
3. 유효하면 새 세션이 생성됩니다.
그런 다음 서버는 세션 데이터를 일반적으로 데이터베이스나 Redis와 같은 인메모리 캐시에 저장합니다.
이 데이터에는 사용자 ID,세션 만료 시간, 기타 메타데이터가 포함될 수 있습니다.
4. 서버는 일반적으로 쿠키 형식으로 고유한 세션 ID가 포함된 응답을 다시 보냅니다.
5. 페이지 접근과 같은 후속 요청 시
6. 클라이언트는 각 요청과 함께 자동으로 세션 ID 쿠키를 보냅니다.
7. 서버는 세션 ID를 가져와 세션 저장소에서 해당 세션 데이터를 조회하고
해당 데이터를 사용하여 요청을 인증하고 처리합니다.
중요한 점은 세션 기반 인증의 경우, 서버가 세션 데이터 생성 및 저장을 담당한다는 것입니다.
그런 다음 세션 ID를 키로 사용하여 향후 요청 시 이 데이터를 검색합니다.
세션의 한 가지 장점은 세션 취소가 간단하다는 것입니다.
세션 데이터는 서버에 저장되므로 서버는 언제든지 세션을 삭제하거나 만료 처리를 하여 무효화할 수 있습니다. 예를 들어, 사용자가 로그아웃하거나 관리자가 특정 사용자의 접근을 차단하고자 할 때 사용됩니다.
인증에서의 무효화란
사용자의 로그인 상태나 접근 권한을 취소하는 과정입니다.
보안상의 이유로 사용자의 세션이나 토큰을 더 이상 유효하지 않게 만드는 작업입니다.
하지만 애플리케이션이 여러 서버에서 실행되는 분산 시스템에서는 모든 서버가 동일한 세션 데이터에 액세스해야 합니다. 이는 일반적으로 Redis 또는 분산 SQL 데이터베이스와 같이 모든 서버가 액세스할 수 있는 중앙 집중식 세션 저장소를 사용하여 달성됩니다
이 방법은 서버가 세션 저장소로 별도로 이동해야 하므로각 요청에 약간의 복잡성과 잠재적인 지연 시간이 추가됩니다
2. JWT
1. 먼저 사용자는 로그인 사용자 인증 정보를 서버에 보냅니다.
2. 서버는 이러한 자격 증명을 확인합니다.
3. 유효하면 JWT가 생성됩니다.
서버는 비밀 키로 JWT에 서명합니다.
이 서명은 토큰의 무결성을 보장하여 변조를 방지합니다.
4. 서버는 일반적으로 응답 본문을 통해 JWT를 클라이언트에 다시 보냅니다.
클라이언트는 일반적으로 로컬 저장소나 쿠키에 JWT를 저장합니다.
5.6. 후속 요청에서 클라이언트는 요청 헤더에 JWT를 보냅니다.
7. 서버는 JWT 서명을 확인합니다.
8. 유효한 경우 서버는 토큰의 데이터를 신뢰하고 이를 인증 및 승인에 사용합니다.
여기서 중요한 차이점은 JWT를 사용하면 서버가 세션 상태를 저장하지 않는다는 것입니다.
필요한 모든 데이터는 클라이언트에 저장되는 토큰 자체에 포함되어 있습니다.
이는 JWT를 상태 비저장(Stateless: 무상태성)으로 만듭니다.
JWT 서명에는 여러 가지 알고리즘을 사용할 수 있으며 그 중 HMAC, RSA, ECDSA가 가장 일반적입니다.
HMAC는 대칭형 서명 방법입니다.
즉, 동일한 비밀 키가 토큰 서명 및 확인에 사용된다는 의미입니다.
이는 더 간단하고 효율적이지만 토큰을 확인해야 하는 모든 서비스와 비밀 키를 공유해야 하므로
보안 문제가 발생할 수 있습니다.
반면 RSA와 ECDSA는 비대칭 서명 방법입니다.
개인 키를 사용하여 토큰에 서명하고 공개 키를 사용하여 토큰을 확인합니다.
이를 통해 개인 키가 비밀로 유지되고 서명에만 사용되는 동시에 모든 서비스에서
공개 키를 사용하여 토큰을 확인할 수 있는 보다 안전한 아키텍처가 가능해졌습니다.
그러나 이로 인해 HMAC에 비해 약간의 복잡성과 계산 오버헤드가 추가됩니다.
서명 알고리즘 선택은 보안 요구사항 및 시스템 아키텍처에 따라 다릅니다.
모놀리식 애플리케이션이 있거나 시스템의 모든 서비스를 신뢰하는 경우 HMAC로 충분할 수 있습니다.
하지만 마이크로서비스 아키텍처가 있거나 JWT를 신뢰할 수 없는 타사 서비스와 공유해야 하는 경우
RSA 또는 ECDSA가 더 안전한 솔루션을 제공합니다.
JWT의 한 가지 과제는 토큰 만료를 처리하는 것입니다.
토큰을 도난당한 경우 만료될 때까지 사용할 수 있습니다.
이를 완화하려면 refresh 토큰을 access토큰과 함께 사용할 수 있습니다.
access 토큰은 각 요청의 인증에 사용되는 실제 JWT입니다.
만료 시간은 일반적으로 약 15분으로 짧습니다.
반면 refresh 토큰은 만료 시간이 훨씬 길어 며칠 또는 몇 주 정도 걸릴 수 있습니다.
access 토큰이 만료되면 사용자에게 다시 로그인하도록 요구하는 대신
클라이언트는 refresh 토큰을 서버의 특수 토큰 엔드포인트로 보낼 수 있습니다.
서버는 refresh 토큰이 유효하고 취소되지 않았는지 확인합니다.
모든 것이 확인되면 서버는 새 access 토큰을 발급합니다.
이 프로세스는 사용자의 상호작용 없이 백그라운드에서 진행됩니다.
이 접근 방식은 보안과 사용자 경험 간의 균형을 유지합니다.
단기 access 토큰은 토큰이 도난당할 경우 잠재적인 오용 가능성을 제한하는 반면,
장기 refresh 토큰을 사용하면 사용자가 반복적으로 로그인할 필요 없이 장기간 인증 상태를 유지할 수 있습니다
refresh 토큰은 모든 요청이 아니라 access 토큰이 만료된 경우에만 전송된다는 점에 유의하는 것이 중요합니다. access 토큰은 인증이 필요한 모든 요청마다 전송됩니다.
그렇다면 언제 세션 기반 인증을 사용해야 하며 언제 JWT가 더 나은 선택일까요?"
세션 기반 인증은 세션을 즉시 취소하는 기능이 필요할 때 적합합니다.
사용자가 자신의 계정이 손상되었다고 신고하면 서버 측에서 해당 세션을 즉시 무효화할 수 있습니다.
다른 목적을 위한 중앙 집중식 데이터 저장소가 이미 있는 경우에도 세션을 선택하는 것이 좋습니다.
이 경우 세션 저장을 위해 기존 인프라를 활용할 수도 있습니다.
그러나 중앙 집중식 세션 저장소를 사용하면 서버가 저장소에서 세션 데이터를 가져와야 하므로
각 요청에 약간의 지연 시간이 추가된다는 점을 명심하는 것이 중요합니다
마지막으로 세션은 민감한 데이터를 서버에 보관하므로 보안상 이점이 있을 수 있습니다.
반면에 JWT는 stateless 아키텍처가 필요할 때 탁월한 선택입니다.
JWT는 필요한 모든 데이터를 토큰 자체에 저장하므로 서버는 메모리나 데이터베이스의 세션을 추적할 필요가 없습니다. 이렇게 하면 여러 서버에 걸쳐 애플리케이션을 수평적으로 확장하는 것이 훨씬 더 쉬워집니다.
JWT는 인증 데이터를 다른 서비스와 공유해야 하는 경우에도 유용합니다.
예를 들어 마이크로서비스 아키텍처에서는 인증 서비스에서 생성된 JWT를 요청마다 인증 서비스에 연결할 필요 없이 다른 서비스에서 확인하고 신뢰할 수 있습니다
stateless 아키텍처가 필요한 상황은?
- 확장성 (Scalability)
서버를 수평적으로 쉽게 확장해야 할 때
로드 밸런싱을 효과적으로 구현해야 할 때 - 마이크로서비스 아키텍처
여러 독립적인 서비스 간 통신이 필요할 때
각 서비스가 독립적으로 동작해야 할 때 - 클라우드 환경
서버리스 아키텍처를 사용할 때
동적으로 리소스를 할당하고 해제해야 할 때 - 성능 최적화
서버 메모리 사용을 최소화해야 할 때
요청 처리 속도를 높여야 할 때 - 다중 디바이스 지원
웹, 모바일, IoT 등 다양한 클라이언트를 지원해야 할 때 - API 중심 아키텍처
RESTful API를 설계하고 구현할 때 - 고가용성 시스템:
서버 장애 시 빠른 복구와 전환이 필요할 때
궁극적으로 선택은 애플리케이션의 특정 요구 사항과 아키텍처에 따라 달라집니다.
참고 bytebytego youtube
https://youtu.be/fyTxwIa-1U0?si=oSofiVSkz4Xzj9ZF
'CS' 카테고리의 다른 글
| [CS] 객체와 배열의 작업 / 메서드에 따른 시간 복잡도 (0) | 2024.10.19 |
|---|---|
| [CS] 알고리즘의 공간 복잡도(Space Complexity)란? (0) | 2024.10.11 |
| Browser Data Stroage 종류와 차이점 (0) | 2023.01.12 |
| [CS] 빅 오 표현법(Big O Notation) 시간 복잡도 (0) | 2022.06.22 |
