쿠키, 세션, JWT 및 토큰에 대한 철저한 이해(강력 권장)

기사 디렉토리

소개: http는 상태 비저장 프로토콜입니까? 그것을 해결하는 방법?

Stateless는 프로토콜에 트랜잭션 처리를 위한 메모리 기능이 없음을 의미합니다 . 상태가 없다는 것은 후속 처리를 위해 이전 정보가 필요한 경우 다시 전송해야 함을 의미하므로 잠재적으로 연결당 전송되는 데이터 양이 증가할 수 있습니다. HTTP의 상태 비저장 특성은 이러한 응용 프로그램의 구현을 심각하게 방해합니다.결국 상호 작용은 과거와 미래를 연결해야 합니다.간단한 장바구니 프로그램은 또한 사용자가 이전에 선택한 제품을 알아야 합니다. 그 결과 HTTP 연결 상태를 유지하기 위한 두 가지 기술이 생겨났습니다. 하나는 쿠키이고 다른 하나는 세션입니다.

1. 쿠키 및 세션

쿠키는 서버에서 반환된 일부 사용자 정보를 저장하는 데 사용할 수 있으며 각 요청에는 이러한 쿠키가 포함됩니다. 서버가 요청 헤더에서 쿠키의 정보를 얻으면 요청 소스를 식별할 수 있으며 http는 상태 저장이 됩니다.

서버 측에서 상태를 유지하는 솔루션은 클라이언트 측에서도 식별자를 저장해야 하므로 세션 메커니즘은 식별자를 저장하는 목적을 달성하기 위해 쿠키 메커니즘을 사용해야 할 수도 있습니다. 쿠키는 그다지 안전하지 않습니다.다른 사람이 로컬에 저장된 쿠키를 분석하여 쿠키를 속일 수 있습니다. 보안을 고려하여 세션을 사용해야하며 세션은 일정 기간 동안 서버에 저장됩니다. 방문 횟수가 증가하면 서버의 성능을 차지하므로 서버의 성능을 낮추기 위해서는 쿠키를 사용해야 합니다.

1.1 쿠키에 대한 참고 사항:

1,쿠키는 클라이언트 측(브라우저 측)에 저장됩니다., 따라서 안전하지 않으며 사람이 지울 수 있습니다. 쿠키는 서버가 이용자의 브라우저에 보내는 아주 작은 데이터로, 로컬에 저장되며, 다음에 브라우저가 동일한 서버에 요청할 때 서버로 옮겨져 보내집니다.
2,쿠키에는 만료 시간 설정이 있습니다.. 만료 시간을 설정하지 않으면 쿠키가 현재 브라우저의 세션 시간임을 의미하며, 브라우저를 닫으면 쿠키가 존재하지 않습니다. 만료 시간이 있는 경우 쿠키는 하드 디스크에 저장되며 브라우저를 닫아도 쿠키에 영향을 미치지 않습니다. 다음에 브라우저를 열 때 쿠키가 여전히 존재합니다
3.쿠키는 사용자가 비활성화할 수 있습니다.
4、쿠키에는 크기 제한이 있습니다., 브라우저가 생성할 수 있는 최대 쿠키 수는 300개이며 각 쿠키 는 4KB 를 초과할 수 없으며 각 웹 사이트에서 설정할 수 있는 쿠키의 총 수는 20개를 초과할 수 없습니다.
5.쿠키는 교차 도메인이 아닙니다.: 각 쿠키는 하나의 도메인 이름에 바인딩되어 다른 도메인 이름으로 획득 및 사용할 수 없으며 1단계 도메인 이름과 2단계 도메인 이름(도메인에 의존) 간에 공유 사용이 허용됩니다.

1.2 쿠키의 중요한 속성

속성 이름	설명하다
문자열 이름	이 쿠키의 이름입니다 . 쿠키가 생성되면 이름을 변경할 수 없으며 문자열 유형이어야 합니다.
개체 값	이 쿠키의 값입니다 . 값이 유니코드 문자인 경우 문자 인코딩이어야 합니다. 값이 바이너리 데이터인 경우 BASE64 인코딩을 사용해야 합니다.
정수 최대 나이	쿠키의 만료 시간( 초)입니다. 양수인 경우 쿠키는 maxAge 초 후에 만료됩니다. 음수일 경우 쿠키는 임시 쿠키로 브라우저를 닫은 후에는 무효가 되며 브라우저는 어떠한 형태로도 쿠키를 저장하지 않습니다. 0이면 쿠키를 삭제한다는 의미입니다. 기본값은 -1입니다.만료보다 낫다
정수 만료	쿠키 만료 시간 을 설정합니다. 쿠키는 설정한 시간이 지나면 만료됩니다.
부울 보안	쿠키가 보안 프로토콜을 통해서만 전송되는지 여부 . 보안 프로토콜. 보안 프로토콜에는 데이터를 네트워크로 전송하기 전에 암호화하는 HTTPS, SSL 등이 있습니다. 기본값은 false입니다.보안 값이 true일 때,쿠키는 HTTP에서 유효하지 않으며 HTTPS에서만 유효합니다.
문자열 경로	이 쿠키의 사용 경로입니다 . "/love/"로 설정하면 contextPath가 "/love"인 프로그램만 쿠키에 액세스할 수 있습니다. "/"로 설정하면 이 도메인 이름 아래의 contextPath가 쿠키에 액세스할 수 있습니다. 마지막 문자는 "/"여야 합니다.
문자열 도메인	쿠키가 사용될 도메인을 결정합니다 . 기본값은 현재 도메인 이름입니다.
정수 버전	이 쿠키가 사용하는 버전 번호 입니다. 0은 Netscape의 쿠키 사양을 따르고 1은 W3C의 RFC 2109 사양을 따릅니다.
Http만	쿠키는 js에서 읽을 수 없지만 응용 프로그램에서 여전히 쿠키를 수동으로 수정할 수 있으므로 XSS 공격을 어느 정도 방지할 뿐이며 절대적으로 안전하지 않습니다.

1.3 세션 노트:

1,세션은 서버에 사용자 정보를 저장하는 것입니다., 서버에 접근하는 사용자가 많아지면 서버에 점점 더 많은 세션이 있게 되고, 세션은 서버에 부담을 주어 서버의 부하에 영향을 미치게 됩니다. 세션의 내용이 너무 복잡하면, 많은 수의 클라이언트가 서버에 액세스하면 메모리 부족이 발생할 수도 있습니다.
2,사용자 정보가 손실되거나 사용자가 이 서버에 액세스하지 않으면 데이터베이스가 손실됩니다.. 그것이 단점입니다. 이제 위의 문제를 해결할 수 있는 세션 공유, iphash, 세션 지속성 등과 같은 몇 가지 기술이 있습니다.
삼.쿠키가 비활성화되면 세션도 비활성화됩니다.. 쿠키는 세션을 구현하는 한 가지 방법일 뿐입니다. 가장 일반적으로 사용되지만 유일한 방법은 아닙니다. 쿠키를 비활성화한 후 URL에 넣는 것과 같이 쿠키를 저장하는 다른 방법이 있습니다.
4. 세션은 쿠키를 기반으로 구현되며 세션은 서버 측에 저장되고 sessionId는 클라이언트의 쿠키에 저장됩니다.
여기에 이미지 설명 삽입
위의 과정을 보면 SessionID가 Cookie와 Session 을 연결하는 다리임을 알 수 있으며, 대부분의 시스템에서도 이 원칙에 따라 사용자의 로그인 상태를 확인합니다. 그러나 이 모델의 가장 큰 문제 는 분산 아키텍처가 없으면 수평 확장을 지원할 수 없다는 것 입니다. 서버를 사용하는 경우 이 모드는 완전히 괜찮습니다. 다만, 서버 클러스터나 서비스 지향적인 크로스 도메인 아키텍처인 경우에는 세션 데이터를 저장하고 공유하기 위한 통합 세션 데이터베이스 라이브러리가 필요하므로 로드 밸런싱을 받는 각 서버가 사용자의 신원을 정확하게 인증할 수 있다.
이 문제를 해결하기 위해 토큰을 사용할 수 있습니다. 아래 토큰에 대한 설명을 참조하십시오.

1.4 쿠키와 세션의 차이점:

위의 설명을 바탕으로 마지막으로 일반적인 차이점을 요약해 보겠습니다.
보안: 세션은 쿠키보다 더 안전하고 세션은 서버 측에 저장되며 쿠키는 클라이언트 측에 저장됩니다.
접근 값의 유형이 다릅니다 . 쿠키는 문자열 데이터만 저장하도록 지원하고 세션은 모든 유형의 데이터를 저장할 수 있습니다.
다른 유효 기간: 쿠키는 기억하기 (기본 로그인) 및 우리가 자주 사용 하는 기타 기능과 같이 장기간 보관되도록 설정할 수 있습니다 . 일반적으로 세션이 짧은 시간 만료되고 클라이언트가 닫히거나(기본적으로) 세션 시간이 초과되었습니다.
저장소 크기가 다릅니다. 단일 쿠키로 저장되는 데이터는 4K를 초과할 수 없으며 세션은 쿠키보다 훨씬 많은 데이터를 저장할 수 있지만 방문이 너무 많으면 서버 리소스를 너무 많이 차지하게 됩니다.

참고:
지금은 대부분이 세션 + 쿠키이지만 쿠키가 없는 세션 또는 세션이 없는 쿠키만 이론적으로 세션 상태를 유지할 수 있습니다. 그러나 실제로는 여러 가지 이유로 단독으로 사용되지 않는 것이 일반적이며 세션 없이 쿠키만 사용하면 모든 계정 정보가 클라이언트 측에 저장되고 한 번 도용되면 모든 정보가 유출됩니다. 그리고 클라이언트 데이터의 양이 많아지고 네트워크를 통해 전송되는 데이터의 양도 많아집니다.
세션을 사용하는 경우 클라이언트 측에서는 id만 저장하면 되며, 실제로 서버 측에서는 많은 양의 데이터가 저장됩니다. 모든 쿠키를 사용하면 데이터 양이 많을 때 클라이언트의 공간이 많지 않습니다.
간단히 말해서 세션은 사용자의 정보(이름, 상태 등)를 포함하는 사용자 정보 테이블과 같습니다. 쿠키는 사용자 패스입니다.

2. 토큰(토큰)

토큰은 그 이름에서 알 수 있듯 토큰이자 인증서이자 키이며, 이 키로만 문을 열 수 있습니다 . 토큰은 일반적으로 웹 시스템과 같은 서버에서 생성되며, 사용자가 로그인하면 서버에서 사용자 이름과 비밀번호를 확인한 후 토큰을 생성하여 클라이언트에게 반환하고 클라이언트는 토큰을 저장(HTTP 헤더에 넣음)하면 모든 후속 요청에 이 토큰이 전달됩니다. 서버는 현재 토큰이 존재하고 만료되었는지 여부를 판별합니다. 토큰이 존재하지 않거나 만료되면 요청이 거부됩니다.

단순 토큰의 구성: uid (사용자 고유 ID), 시간 (현재 시간의 타임스탬프), 기호 (서명, 토큰의 처음 몇 자리는 해시 알고리즘에 의해 특정 길이의 16진수 문자열로 압축됨)

2.1 토큰의 장점

1.토큰은 애플리케이션에서 완전히 관리되므로 동일 출처 정책을 피할 수 있습니다.
2.안전. 토큰은 CSRF 공격(쿠키가 필요하지 않기 때문에)을 피할 수 있습니다.
CSRF 공격(교차 사이트 요청 위조) : 공격자가 귀하의 ID를 도용하고 귀하의 이름으로 악의적인 요청을 보냅니다 . CSRF가 할 수 있는 일에는 다음이 포함됩니다: 귀하의 이름으로 이메일 보내기, 메시지 보내기, 귀하의 계정 도용, 심지어 상품 구매, 가상 화폐 이전... 발생한 문제는 다음과 같습니다. 개인 정보 유출 및 재산 보안. (CSRF 공격이 무엇인지 알고 싶다면 댓글 영역에서 토론할 수 있습니다.)
3.상태 비저장 및 확장 가능, 여러 서비스 간에 공유 가능
4.다중 플랫폼 교차 도메인: CORS(Cross-Origin Resource Sharing)가 응용 프로그램과 서비스를 확장할 때 다양한 장치와 응용 프로그램이 관련되어야 합니다. 사용자에게 인증된 토큰이 있는 한 모든 도메인에서 데이터와 리소스를 요청할 수 있습니다.

2.2 토큰 인증 절차

여기에 이미지 설명 삽입

3. JWT 기반 토큰 인증 방식

토큰을 생성할 때 몇 가지 옵션을 설정할 수 있습니다. 그러나 JSON Web Tokens 에서는 표준 사용이 단축 됩니다.JWT반영하다.
JWT(JSON Web Token)는 현재 가장 널리 사용되는 도메인 간 인증 솔루션입니다.

3.1 JWT 구성 요소

JSON 웹 토큰 토큰은 점(. )으로 구분된 간결한 형태의 세 부분으로 구성되며 다음과 같습니다.

헤더: 헤더
페이로드: 페이로드
서명: 서명

여기에 이미지 설명 삽입
개체는 매우 긴 문자열이며 문자는 "." 구분 기호로 세 개의 하위 문자열로 나뉩니다. 각 하위 문자열은 기능 블록을 나타내며 JWT 헤더, 페이로드 및 서명
의 총 세 부분으로 구성됩니다.

3.1.1 헤더: 헤더

헤더는 일반적으로 토큰 유형(예: JWT)과 사용된 서명 알고리즘(예: HMAC SHA256 또는 RSA)의 두 부분으로 구성됩니다.
예:

 此JSON被Base64Url编码以形成JWT的第一部分。
{
    
    
"alg": "HS256",表示签名使用的算法，默认为HMAC SHA256（写为HS256）
"typ": "JWT"表示令牌的类型，JWT令牌统一写为JWT
}

3.1.2 페이로드: 페이로드

페이로드 부분은 JWT의 주요 콘텐츠 부분이며 전달할 데이터를 포함하는 JSON 객체이기도 합니다. JWT
는 선택할 7개의 기본 필드를 지정합니다.

iss: 발행자
exp: 만료 시간
sub: 주제
aud: 사용자
nbf: 그때까지 사용할 수 없음
Iat: 발행 시간
jti: 이 JWT를 식별하는 데 사용되는 JWT ID

위의 기본 필드 외에도 개인 필드를 사용자 지정할 수도 있습니다. 페이로드의 예는 다음과 같습니다.

{
    
    
"sub": "9876543210",
"name": "Mr Fen",
"admin": true
请注意，默认情况下JWT是未加密的，任何人都可以解读其内容，因此不要构建隐私信息字段，存放保密信息，以防止信息泄露。
}

3.1.3 페이로드: 서명

서명된 부분을 생성하려면 인코딩된 헤더, 인코딩된 페이로드, 키, 헤더에 지정된 알고리즘을 가져와서 서명해야 합니다.
예를 들어 HMAC SHA256 알고리즘을 사용하는 경우 서명은 다음과 같은 방식으로 생성됩니다.

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(claims), secret)

3.2 JWT는 언제 사용해야 합니까?

1. JWT를 사용하는 가장 일반적인 시나리오인 인증 . 사용자가 로그인하면 각 후속 요청에는 JWT가 포함되어 사용자가 해당 토큰에서 허용하는 경로, 서비스 및 리소스에 액세스할 수 있습니다. 싱글 사인온은 오버헤드가 적고 여러 도메인에서 쉽게 사용할 수 있기 때문에 오늘날 JWT와 함께 널리 사용되는 기능입니다.
2. 정보 교환, JWT 토큰은 당사자 간에 정보를 안전하게 전송하는 좋은 방법 입니다. JWT에 서명할 수 있기 때문에(예: 공개/개인 키 쌍으로) 보낸 사람이 누구인지 확인할 수 있습니다. 또한 헤더와 페이로드를 이용하여 서명을 계산하기 때문에 내용이 변조되지 않았음을 확인할 수도 있습니다.

3.3 JWT와 토큰의 관계는 무엇입니까?

토큰은 특정 규칙 에 따라 생성된 문자열 이며 사용자 정보를 포함합니다.
일반적으로 표준 사용 JWT를 사용합니다.
JWT는 우리를 위한 규칙을 규정하는 것인데, JWT를 사용하여 사용자 정보가 포함된 문자열을 생성할 수 있습니다.