상태 비저장 및 상태 저장 아키텍처

애플리케이션의 상태, 즉 주어진 시간에서의 상태 또는 품질을 나타냅니다. 상태 비저장 인증에는 정적 콘텐츠만 포함하고 저장된 세션이나 사용자가 없습니다. 이는 동적 콘텐츠인 상태 저장과 다릅니다.

상태 비저장 프로세스는 다른 서비스나 다른 시스템과의 상호 작용을 참조하지 않는 격리된 리소스입니다. 상태 비저장 인증은 이러한 유형의 데이터를 저장하지 않기 때문에 이전 트랜잭션에서 정보를 가져오지 않고 코드의 해당 부분에서만 작동합니다. 각 작업은 처음부터 수행됩니다.

상태 기반 인증을 사용하면 정보를 한 번 이상 사용할 수 있으며 이전 거래의 컨텍스트를 기반으로 실행됩니다. 따라서 다른 시스템이나 데이터베이스에 존재하든 응답이나 기존 데이터를 기다려야 하는 애플리케이션에서는 상태 저장이 사용됩니다.

무상태 인증

상태 비저장 인증은 자격 증명을 제공한 후 사용자가 응답으로 액세스 토큰을 받는 전략으로 구성됩니다. 이 토큰에는 토큰을 발행한 서비스나 데이터베이스에 지속적으로 문의할 필요 없이 토큰을 생성한 사용자를 식별하는 데 필요한 모든 정보가 이미 포함되어 있습니다.

이 토큰은 클라이언트측에 저장(브라우저)되므로 서버는 페이로드와 서명이 일치하는지 확인하여 토큰의 유효성을 확인할 수만 있습니다.

무상태 인증 JWT

JSON 웹 토큰(JWT)은 RFC-7519에 확립된 표준을 갖춘 키로, 호출할 필요 없이 독립적인 선언 형식의 엔터티를 포함합니다. 토큰을 재검증하기 위한 서버입니다.

문자열은 다음 예와 같이 비밀 키를 사용하여 base64 표준으로 인코딩됩니다.

장점과 단점

장점:

• 서버 메모리 소비가 낮습니다.
• 확장성 측면에서 우수합니다.
• API 및 마이크로서비스와 같은 분산 애플리케이션에 이상적입니다.
• 제3자에 의존하지 않고 격리된 애플리케이션에서 토큰을 생성 및 배포합니다.
• 토큰 사용자 데이터를 쉽게 해석하고 검증합니다.

단점:

• 접근 제어가 어렵습니다.
• 토큰은 언제든지 쉽게 취소할 수 없습니다.
• 누군가 토큰에 접근할 수 있는 경우 악의적인 제3자의 진입을 용이하게 할 수 있습니다.
• 토큰이 만료될 때까지 세션을 변경할 수 없습니다.
• JWT 토큰은 더 복잡하며 모놀리스와 같은 중앙 집중식 애플리케이션에서는 불필요해질 수 있습니다.

상태 저장 인증

다양한 애플리케이션, 특히 확장성이 많이 필요하지 않은 애플리케이션에서 흔히 사용되며, 애플리케이션의 백엔드에서 상태 저장 세션을 생성하고 세션 참조를 해당 사용자에게 다시 보냅니다. . 사용자가 요청할 때마다 애플리케이션의 일부가 토큰을 생성합니다. 그 순간부터 새로운 요청이 있을 때마다 이 토큰이 애플리케이션에 다시 전송되어 액세스 유효성을 다시 검사하게 됩니다. 이 모델에서는 사용자 데이터에 변경이 있는 경우 토큰을 쉽게 취소할 수 있습니다.

이는 불투명 액세스 토큰, 즉 해당 토큰과 관련된 식별자나 사용자 데이터를 포함하지 않는 독점 형식의 단순 문자열입니다. 수신자는 토큰을 생성한 서버를 호출하여 토큰을 검증해야 합니다.

예제 토큰: 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

이 ID는 토큰을 소유한 사용자와 함께 데이터베이스에 저장되어야 합니다.

장점과 단점

장점:

• 중앙집중화된 구현 로직.
• 간소화된 액세스 관리 및 제어.
• 모놀리스, MVC 애플리케이션 및 내부 프로세스에 탁월합니다.
• 악의적인 제3자로부터 더욱 안전해졌습니다.

단점:

• 토큰 검증을 담당하는 API에 과부하가 있을 수 있습니다.
• 확장성 측면에서 실패했습니다.
• 마이크로서비스 간 인증 배포가 더 어려워졌습니다.
• 분산 애플리케이션에서는 인증 서비스가 실패하면 다른 모든 서비스를 사용할 수 없게 됩니다.
• 구현이 더 복잡해졌습니다.
• 타사 시스템과의 통합이 더 어렵습니다.

각 접근 방식을 언제 사용해야 합니까?

JWT 토큰 및 상태 비저장 인증을 사용하는 경우

• API 과부하에 대한 걱정 없이 더 높은 성능이 필요한 경우.
• 서비스 간에 여러 개의 통신이 분산되어 있는 경우.
• 시스템 내 다양한 ​​서비스에서 어떤 사용자가 작업을 수행하고 있는지 식별해야 하는 경우.
• 사용자의 데이터를 유지하려는 의도가 아닌 경우 초기 등록만 합니다.
• 서비스에 대한 외부 접근을 생성해야 하는 경우.
• 시스템에 최소한의 영향을 미치면서 특정 작업을 수행하는 사람의 데이터를 조작해야 하는 경우.

불투명 토큰과 상태 기반 인증을 사용해야 하는 경우

• 시스템 사용자의 전체 액세스 제어가 필요한 경우 주로 액세스 계층을 정의합니다.
• 중앙 집중식 애플리케이션에서 분산 서비스가 없고 외부 서비스와 통신하지 않습니다.

최종 고려사항:

• "API 스트레스"와 같은 일부 위치에서는 명확성을 위해 용어가 "API 오버헤드"로 대체될 수 있습니다.
• 'JWT 토큰' 섹션에는 대상 고객이 더 많은 맥락을 필요로 하는 경우 RFC-7519에 언급된 '선언'이 무엇인지에 대한 더 자세한 설명이 포함될 수 있습니다.
• 상태 저장 인증 섹션에서 "애플리케이션의 한 부분이 토큰을 생성합니다"라는 문구는 애플리케이션의 어느 특정 부분이 이를 담당하는지 설명함으로써 명확해질 수 있습니다.