인증에 대해 읽었으며 유형 분류에 대해 혼란스러워졌습니다.

쿠키 기반 인증부터 시작하겠습니다. 올바르게 이해하면 핵심은 사용자 인증에 필요한 모든 데이터가 쿠키에 저장된다는 것입니다. 그리고 이것은 나의 첫번째 혼란입니다 : 쿠키에 우리는 저장할 수 있습니다

• 세션 ID 그래서 세션 기반 인증이됩니까?
• 클레임이므로 클레임 기반 인증이라고해야합니까?
• 일부 사람들은 JWT 토큰을 쿠키에 저장하기도하지만 이것이 자신의 인증 흐름의 사용자 정의 구현처럼 보입니다 ...

이제 클레임 기반 인증으로 전환하겠습니다. 주요 요소는 클레임이며 클레임 모음은 컨테이너로 사용할 수 있습니다.

• 쿠키 (위에서 논의)
• 토큰 (예 : JWT).

우리가 토큰에 관해 이야기 할 때, 다른 종류의 정보를 포함 할 수 있습니다. 예를 들어 세션 ID

그래서 내가 무엇을 놓쳤습니까? 인증 유형에 대해 이야기 할 때 사람들이 인증 Cookie-Session-based이나 이와 유사한 것을 정의하지 않는 이유는 무엇 Token-Claims-based입니까?

다른 개념의 이름이 혼란 스럽다는 데 동의합니다. 웹 컨텍스트에서 인증에 관해 이야기 할 때 고려해야 할 몇 가지 측면이 있습니다.

인증시 클라이언트는 어떤 정보를 전송합니까?

• 세션 ID . 이는 서버에 활성 세션이 포함 된 세션 스토리지가 있음을 의미합니다. 세션은 서버 측에서 상태 저장 됩니다.
• 클레임 집합 . 클레임에는 클라이언트가 수행 할 수있는 작업에 대한 정보가 포함됩니다. 서버는 인증 된 각 클라이언트를 추적하지 않지만 클레임을 신뢰합니다. 클레임은 일반적으로 서버 측에서 상태 비 저장 입니다.

클라이언트는 인증 정보를 어떻게 보냅니 까?

• 쿠키 . 쿠키는 쿠키가 설정된 후 각 요청마다 자동으로 쿠키를 보냅니다. 쿠키는 XSRF에 취약합니다.
• 다른 헤더 . 일반적으로 Authorization 헤더가 사용됩니다. 이 헤더는 브라우저가 자동으로 보내지 않지만 클라이언트가 설정해야합니다. 이것은 XSS에 취약합니다.
• 요청 URL . 인증 정보는 URL에 포함되어 있습니다. 이것은 일반적으로 사용되지 않습니다.

인증 정보의 형식은 무엇입니까?

• 일반, 서명되지 않은 텍스트 . 세션 ID에 사용할 수 있습니다. 세션 ID는 일반적으로 클라이언트가 추측 할 수 없으므로 서버는 클라이언트가 세션을 위조하지 않았다고 신뢰할 수 있습니다.
• JSON 웹 토큰 . JWT는 암호로 서명되며 만료 정보를 포함합니다. 클라이언트는 일반적으로 토큰을 해독 할 수 있지만 서버에 알리지 않으면 토큰을 변경할 수 없습니다.
• 다른 서명 형식 . JWT와 동일 중요한 것은 클라이언트가 데이터를 변경하지 못하게하는 암호화 서명입니다.

보너스 : 클라이언트가 정보를 로컬에 저장하는 방법

• 쿠키 . 쿠키를 사용하여 정보를 전송하는 경우에도 마찬가지입니다. 그러나 쿠키는 클라이언트 측 스토리지 메커니즘으로도 사용될 수 있습니다. 이를 위해서는 스크립트에서 쿠키를 읽을 수 있어야 유용합니다. 예를 들어, 클라이언트는 JavaScript로 쿠키를 읽고 Authorization-Header와 함께 정보를 보낼 수 있습니다.
• 로컬 스토리지 . 쿠키를 사용할 수없는 경우 이것이 가능한 유일한 방법입니다. JavaScript로 관리해야합니다.

사람들이 말할 때 무엇을 의미합니까?

• "쿠키 기반 인증" . 이는 일반적으로 "세션 ID, 쿠키로 전송, 일반 텍스트로 가능"을 의미합니다.
• "토큰 기반 인증" . 일반적으로 이는 "클레임, 인증 헤더를 사용하여 전송, Json 웹 토큰으로 인코딩 됨"을 의미합니다.
• "클레임 기반 인증" . 세션 ID 이외의 것일 수 있습니다.

간단히 말해

1. 쿠키 기반 인증

   • 웹 클라이언트 (예 : 웹 브라우저)는 인증에 성공한 후 웹 서버가 보낸 쿠키를 저장합니다.
   • 쿠키에는 쿠키를 결정하기 위해 사용자, 클라이언트, authN 타임 스탬프 및 unique-id가있는 기타 유용한 데이터에 대한 정보가 포함됩니다.
   • 일반적으로 쿠키는 도메인 속성이 설정된 웹 서버 (예 :)로 암호화되어 google.com웹 클라이언트로 전송됩니다.
   • 웹 클라이언트가 도메인 리소스 (예 :)에 액세스하려고 할 때마다 도메인 (예 mail.google.com:)을 기반으로하는 모든 쿠키를 google.com웹 서버로 보내면 상태 및 타임 스탬프에 따라 액세스를 확인 / 확인하고 액세스를 승인 / 거부합니다. 쿠키.

2. 세션 기반 인증

   • 웹 클라이언트 쿠키와 함께 웹 서버가 사용자 authN 데이터를 백엔드에 저장하면 세션 기반 인증이라고합니다.
   • 이는 웹 클라이언트가 액세스 권한이 없어야하는 시스템에 대한 액세스 권한을 얻은 경우에 매우 유용하며, 백엔드에서 관리자가 웹 클라이언트 세션을 취소 할 수 있습니다.

3. 토큰 기반 인증

   • 일반적으로 이는 클라이언트 측에 쿠키를 저장할 수있는 방법이없는 웹 클라이언트가 아닌 시나리오에서 사용됩니다.
   • 따라서 웹 서버는 인증에 성공한 후 서명 된 토큰 (사용자, 클라이언트, authN 타임 스탬프 및 unique-id가있는 기타 유용한 데이터에 대한 정보를 포함)을 클라이언트에 보냅니다.
   • 클라이언트가 리소스에 액세스하려고 할 때마다이 토큰을 보내야하며 웹 서버는 리소스에 액세스하기 전에 토큰의 유효성을 검사 / 확인합니다.

4. 클레임 기반 인증

   • 이는 토큰 기반 인증과 동일하지만 클라이언트 및 / 또는 클라이언트와 연결된 사용자에 대한 토큰에 더 많은 데이터를 추가해야합니다.
   • 이 데이터는 권한과 관련되며 클라이언트가 자원 내에서 수행해야하는 작업 (예 : mail.read, mail.delete, calendar.read)에 대해 설명합니다.