쿠키, 세션, 토큰의 차이점과 유사점, JWT 이해, 디지털 서명, 서명 인증서

쿠키, 세션, 토큰이란 무엇입니까? 차이점이 뭐야?

쿠키, 세션, 토큰이 필요한 이유는 무엇입니까?

먼저 이 세 가지가 왜 존재하는지 생각해볼 필요가 있습니다. HTTP 프로토콜은 Stateless 특성으로 인해 발생하기 때문입니다. Stateless란 무엇일까요? 예를 들어, 클라이언트와 서버가 요청하고 응답할 때 프로토콜은 요청 처리, 응답 거부 등의 역할만 담당하고 메모리에 대한 책임은 없으므로 문제가 발생합니다. 프로토콜을 검증해야 하지만 프로토콜 자체에는 기억하는 능력이 없기 때문에 모든 요청을 검증하는 것은 당연히 무리입니다.타오바오에 가서 새 페이지로 이동할 때와 마찬가지로 로그인하고 검증해야 합니다. 보통 사람들은 폭발적인 사고방식을 가지고 있기 때문에 세션의 진행을 유지하기 위해 쿠키와 세션이 탄생하게 된 것입니다.이것이 그 목적입니다.물론 토큰은 동일하지만 방법이 약간 다릅니다.

쿠키 및 세션:

먼저 쿠키에 대해 이야기해 보겠습니다. 첫 번째 요점: ① 우리가 기억해야 할 것은 쿠키는 클라이언트에 저장되고, 세션은 서버에 저장된다는 것입니다. 여기에서 이해하면 쿠키는 클라이언트의 손에 있는 열쇠이며, 서버는 호텔이고, 세션은 각 문의 문 잠금 장치입니다. 문 안쪽에 웨이터가 있어 고객과 대화할 수 있습니다. 저장 위치가 다른 것이 중요한 차이점입니다. 예를 들어 세션을 원할 경우 해당 문을 열려면 키를 사용해야 합니다. 세션을 계속하려면 두 번째 사항: ② 쿠키에는 만료 시간이 있습니다. 설정하지 않으면 쿠키는 현재 브라우저 세션 시간이 됩니다. 브라우저가 닫히면 쿠키는 만료됩니다. 만료 시간이 설정되면 쿠키는 하드 디스크에 저장되며, 브라우저를 닫으면 다음에 열 때 쿠키가 계속 존재합니다. 세 번째 사항: ③쿠키에는 크기 제한이 있습니다. 단일 쿠키의 크기는 다음과 같습니다. 4kb입니다. 대부분의 브라우저는 사이트가 최대 20개의 쿠키를 저장하도록 제한합니다. 네 번째 점: ④ 여기서 또 주목해야 할 점은 쿠키는 평문으로 저장되며, 저장 방식은 키-값 쌍이라는 점입니다. 이로 인해 계정 비밀번호 등의 개인정보가 쿠키에 존재할 수 없다는 문제가 노출됩니다. 마찬가지로 쿠키도 위조가 쉽고, 쿠키의 값도 쉽게 변경될 수 있으므로 중요한 정보를 평문으로 저장하면 유출 및 악용이 매우 쉽습니다.

다음으로 이야기할 것은 세션입니다. 방금 세션을 도어락에 비유했는데, 이를 통해 쿠키와 세션의 대응 관계를 더 잘 이해할 수 있습니다. 실제로 세션은 청구서에 비유될 수도 있습니다. 각 세션 동안, 세션은 고객에게 세션 ID를 보냅니다. 쿠키는 클라이언트 측에 저장됩니다. 다음에 세션을 원할 때 쿠키는 해당 청구서 번호를 제시합니다. 세션을 하나씩 검색합니다. 찾을 경우 해당 세션을 시작하면 이전 세션을 계속 시작하게 됩니다. 여기서는 앞의 예를 사용하면 어떨까요? 사실 서버가 초점이기 때문입니다. 클라이언트가 제공한 쿠키, 즉 청구서 번호를 기준으로 찾아보세요. 지금의 예시라면 클라이언트는 해당 문을 찾게 되는데, 이는 타당하지 않지만, 이렇게 되면 세션이 진행되어야 한다는 복선이 깔려 있다. 해당 청구서 번호에 대해 서버는 각 요청마다 프로토콜을 메모리에 저장해야 합니다. 요청량이 크면 이것도 큰 오버헤드입니다. Taobao 및 JD.com과 같은 경우 대규모 고객 기반의 경우 사용자만 저장하면 됩니다. 데이터는 비용이 많이 들고, 데이터를 메모리에 저장한 후 쿠키와 비교해야 하기 때문에 특수한 상황을 고려해야 하므로 단일 서버가 아닌 경우 서비스를 제공합니다(예: 서버 A 먼저) 서비스를 제공하는 클라이언트는 A와 접속을 맺고 해당 세션을 저장하는데, 클라이언트가 분산서버 B에 접근할 경우 세션이 서버에 저장되어 있기 때문에 접속을 할 수 없으므로 분산서버 시스템에 직면할 때 쿠키는 그리고 세션에는 특정 결함이 있으며 이는 토큰 생성의 길을 열어줍니다. 또 다른 주의가 필요한 점은 쿠키에 의해 위조된 데이터는 쉽게 구별할 수 없다는 것입니다. 쿠키와 세션 확인 모드에 해당하는 것은 무엇입니까? 일부 슈퍼마켓에서는 모든 고객에게 멤버십 카드를 발급할 수 있습니다. 쇼핑할 때 확인을 위한 의사 결정권은 고객입니다. 예를 들어, 멤버십 카드를 보여주고 '내가 회원이라면 계산원은 나를 '회원'으로 대할 것입니다. 다만, 누군가 회원카드를 위조하거나, 타인의 카드를 빼앗아 내가 회원이라고 말하면 계산원은 여전히 회원으로 취급합니다.이것이 쿠키의 보안을 위한 처리입니다. 서버는 반환된 정보를 저장을 위해 일반 텍스트로 클라이언트에 반환합니다. 즉, 서버는 귀하가 누구인지 말하며, 이 "누구"는 클라이언트가 쿠키 없이 제시하는 한 서버는확인은 통과되었지만 이제 많은 확인에서는 회원 카드를 사용하기 전에 회원인지 확인하기 위해 회원 카드를 가져가야 한다는 것을 우리 모두 알고 있습니다.

여기에서는 쿠키 및 세션 확인의 단점을 요약하겠습니다(전부는 아니지만 일부는 이해합니다).

①세션은 각 세션별 세션 정보를 메모리에 저장해야 하는데, 이는 과금으로 이해될 수 있으며, 이로 인해 많은 메모리를 차지하게 되고 서버에 부담이 가중됩니다.

②세션에는 한계가 있습니다.단일 서버라면 청구서가 모두 본점에 있기 때문에 문제가 없으나, 분산형 서비스라면 검증할 수 없는 문제가 있습니다.

③서버가 클라이언트에게 쿠키를 보내기 때문에 보안이 높지 않으며, 클라이언트는 쿠키만 보내면 인증을 통과할 수 있습니다.

④앱 등 모바일 애플리케이션은 세션을 무효화합니다.

⑤쿠키는 도메인 간 접근을 허용하지 않습니다.

⑥쿠키의 크기 제한은 4kb입니다.

토큰이란 무엇입니까?

토큰은 서버가 생성한 문자열의 문자열로 클라이언트가 요청한 토큰으로 사용됩니다. 처음 로그인할 때 서버는 클라이언트에 토큰을 생성합니다. 이후 요청에서는 로그인하지 않고도 토큰을 가져올 수 있습니다. 사실 쿠키는 매우 유사하지만 토큰에는 추가 확인 단계가 있습니다. 통과하기 위해 더 이상 제시할 필요가 없습니다. 쿠키에 비해 토큰은 서버에 대한 부담을 줄여줍니다. 토큰을 저장할 필요가 없습니다. 세션과 같이 많은 수의 세션 기록을 보유하고 있으며, 서버는 토큰을 통해 Redis에 사용자 정보를 쿼리하는데, 이는 ① 쿠키의 단점 문제를 해결할 뿐만 아니라 ② 세션이 분산 서비스를 처리할 수 없는 문제도 해결합니다. Redis에서 사용자 정보만 조회하면 되고, 토큰은 크기를 제한하지 않지만 쿠키는 4K에 불과하고, 토큰은 쿠키와 다른 도메인 간 요청을 허용할 수 있으며, 모바일에서 발생하는 문제도 해결합니다. 앱과 같은 애플리케이션은 세션을 무효화합니다. 토큰에는 여러 측면이 있음을 알 수 있습니다. 쿠키에 비해 장점이 있지만 앞서 말했듯이 애플리케이션 시나리오와 결합해야 합니다. 현재 쿠키와 토큰은 모두 매우 일반적으로 사용됩니다. Redis에서 토큰을 쿼리하는 것 외에 다른 방법도 있는데, JWT 형태로 Redis 쿼리를 자주 하면 Redis에 대한 부담도 커지기 때문에 JWT도 마찬가지다. Redis 쿼리에 비해 몇 가지 장점이 있습니다. 저장을 위해 데이터를 브라우저에 전달하고 다음에 요청을 계속해야 할 때 JWT를 전달합니다. 서버는 확인을 수행할 수 있습니다. 이렇게 하면 Redis 쿼리 단계를 피할 수 있고 비용을 줄일 수 있습니다. Redis에 대한 압박감은 어느 정도 있지만, JWT의 보안 문제와 Redis를 통한 토큰 검증에 대한 연구를 많이 하지 않았기 때문에 비즈니스 시나리오를 기반으로 해야 합니다. .

그림 5)

토큰과 쿠키의 보안을 비교할 때 토큰이 더 안전한 이유는 무엇입니까?

우선, 토큰의 보안은 쿠키보다 높습니다. 앞서 언급했듯이 쿠키는 서버가 귀하에게 패스를 발급하는 것과 같습니다. 패스를 제시하기만 하면 인증을 통과할 수 있습니다. 직설적으로 말하면 Zhang San 서버가 Li Si에게 발급한 패스로 동일하게 액세스할 수 있습니다. 데이터, 서버는 귀하가 누구인지 걱정하지 않습니다. 쿠키는 서버가 클라이언트 사용자에게 발급하는 패스입니다. 실제로 토큰과 쿠키는 매우 유사합니다. 그러나 차이점은 토큰에 서명 메커니즘이 추가된다는 것입니다. 서명 메커니즘을 사용하면 데이터 보안이 강화됩니다. 그렇다면 전자 서명 메커니즘은 어떻게 데이터 보안을 보장합니까? 우선, 현재 가장 많이 사용되는 것은 JWT인데, 그림 (5)의 데이터 구조는 토큰 전송 및 인증을 완료하는 데 사용되며 디지털 서명도 여기에 저장됩니다. JWT의 전체 이름은 JSon Web Token입니다. Json 형식으로 전송됨 정보는 디지털 서명되어 있으므로 정보를 신뢰할 수 있음 JWT의 절반은 adb.123ccc.666ad와 유사한 문자열로 구분 기호가 .이고 헤더 세 부분으로 구성됨 , 페이로드 및 서명.

머리글:

{

"alg": "HS256", "typ": "JWT"

}

크게 두 가지 속성이 있는데, typ 속성은 JWT로 일률적으로 작성하고, alg는 암호화에 사용되는 알고리즘을 의미하며 여기서 HS256은 대칭암호화, RS256은 비대칭암호화한다. (예측 1)

유효 탑재량:

여기에 저장되는 것은 다음과 유사한 쿠키와 유사한 데이터입니다.

선택할 수 있는 기본 필드는 7개입니다.

iss (발행자): 발행자/발행자
하위 (주제) : 주제
aud (청중): 사용자
exp (만료 시간): 만료 시간
nbf(Not Before): 유효 시간, 이 시간 이전에는 유효하지 않습니다.
iat (Issued At) : 발급 시간
jti (JWT ID): JWT를 식별하는 데 사용됩니다.

{

"iss"："zs",

"sub":"123",

"sex"："男" //同样允许写入自定义的字段

}

JWT의 json 객체는 단순히 Base64를 사용하여 암호화된다는 점에 주목할 필요가 있습니다. 이 암호화는 되돌릴 수 있으므로 역방향 인코딩을 통해 원본 텍스트를 얻을 수 있으므로 민감한 데이터는 여전히 JWT에 배치될 수 없습니다.

서명:

JWT의 세 번째 부분인 시그니처(Signature) 역시 중요한 부분입니다. 이것을 보고 궁금한 점이 많았고, 궁금증을 해결하기 위해 관련 지식도 검색해 보았습니다. 이것은 처음 두 부분인 헤더를 합친 것입니다. 페이로드 정보는 먼저 문자열 형식으로 Base64 암호화된 후 HS256 암호화 후 얻은 데이터와 같이 헤더에 선언된 암호화 방법을 사용합니다. 데이터가 변조되지 않은 경우 복호화된 비밀 데이터는 base64 역파싱 후 얻은 데이터가 헤더, 페이로드와 동일 데이터의 보안성을 초기에 확인하는 단계로, 예를 들어 클라이언트는 JWT를 서버로 보내고, 서버는 Signature 부분을 복호화한다. 페이로드와 헤더가 전송된 것과 동일한 것을 확인하고, 평문 페이로드와 헤더가 일치하지 않으면 해당 정보가 변조되었음을 증명합니다.여기서 Signature를 서명이라 부르며, 이는 사용자의 서명과 동일합니다. 그러면 이 과정은 어떻게 진행되나요?이렇습니다.사용자가 처음 로그인에 성공한 후 몇 가지 정보가 있을 것입니다.서버는 이를 HS256 및 기타 방법을 통해 암호화합니다.쿠키에 저장된 정보 및 기타 정보를 암호화하여 사용자의 성공적인 로그인을 검증하고 이를 Signature 인증서에 저장하고 이를 우리를 위해 서명하는 Yi xx와 같은 배포가 가능한 지점입니다.HS256이 왜 대칭 암호화 방식인지 고민하기 시작했습니다.대칭 암호화이기 때문입니다. 키를 제대로 보관해야 합니다.(전송이 불편합니다. 자세한 이유는 나중에 설명하겠습니다.) 나중에서야 깨달았습니다. , 사실 이 과정에는 사용자 참여가 없습니다. 사용자, 즉, 클라이언트는 암호화 및 복호화 과정에 참여하지 않으며 정보를 암호화하고 복호화하는 것은 서버입니다. 즉, 사용자의 로그인 여부를 확인하기 위해 쿠키와 유사한 정보를 서버에서 암호화한 후, 우리에게 반환되면 저장했다가 다음번 사용시 서버에 전송하고, 서버는 키를 복호화하여 정보가 변조되었는지 확인하고, 변조되지 않았다면 통과시킵니다. 서버가 암호화를 하고 있습니다. 키는 서버에서만 알 수 있으며, 클라이언트와 서버 간에 키를 전송할 필요가 없기 때문에 보안상의 문제가 없습니다. 확실히 비대칭 암호화보다 낫습니다.), 이것이 바로 JWT가 주로 키를 전송할 필요가 없기 때문에 더 안전하다고 생각하는 RS256(비대칭 암호화) 대신 HS256을 사용하는 이유이므로 비즈니스 시나리오가 매우 중요합니다. 우리가 언급한이것으로 디지털 서명이 무엇인지, 디지털 서명의 정확성을 보장하는 방법은 무엇인지, 대칭 암호화와 비대칭 암호화의 차이점에 대해 생각하지 않을 수 없어서 자세히 알아보러갔습니다.

그림 1)

먼저, 디지털 서명이란 무엇입니까?

먼저 RSA 디지털 서명 알고리즘을 예로 들어 보겠습니다. (비대칭 암호화)

위의 그림(1)과 같이 Xiao Ming은 파일이 자신의 소유인지 확인하기 위해 파일에 디지털 서명을 해야 하며, 그러면 RSA 디지털 서명 알고리즘에 따라 공개 키와 개인 키가 생성됩니다. 공개키와 개인키는 문자 그대로의 키가 아니며 공개키와 개인키의 차이점은 공개키는 인터넷에 공개되거나 외부에 공지된다는 점입니다. 개인키는 개인이 보관하는데, 예를 들어 공개키로 데이터를 암호화할 수 있다면 개인키를 소유한 사람은 개인키를 복호화하여 원본을 얻을 수 있다. 개인 키를 사용하면 공개 키를 복호화하여 원본 텍스트를 얻을 수 있습니다. 비대칭 암호화의 한 가지 특징은 개인 키 암호화를 전제로 하는 경우 공개 키만 알고 있으면 원본 텍스트를 얻을 수 없으므로 다음과 같은 시나리오가 발생합니다.

A회사는 자신의 공개키 A와 개인키 A를 갖고, B회사는 자신의 공개키 B와 개인키 B를 가지고 있습니다.

(여기서는 HS256과 같은 대칭암호가 무엇인지 소개합니다. 대칭암호는 실제로 암호화와 복호화에 하나의 키를 사용하는 것을 의미합니다. 그러나 암호화와 복호화에 하나의 키를 사용하므로 키의 저장과 전송이 문제가 됩니다. 누군가 가로채면 키 정보를 이용해 모든 데이터를 얻을 수 있고, 키 보관도 문제다)

A회사가 B회사에 중요한 개인정보를 보내고자 할 경우 B회사의 공개키로 암호화하고, 전송해야 하는 데이터를 대칭적으로 암호화한 후 암호화된 키를 B회사에 보낼 수 있습니다. 해당 개인키를 가지고 있는 회사만이 획득한 정보의 내용을 복호화할 수 있으며, 획득한 키를 사용하여 대칭적으로 암호화된 정보를 복호화할 수 있어 정보의 보안이 보장됩니다. 비대칭 암호화가 더 안전하지만 암호화와 복호화에 상대적으로 시간이 많이 걸리기 때문에 정보를 대칭적으로 암호화한 후 암호화된 정보와 키가 수신자에게 전송되므로 보안을 보장하면서 복호화 효율성이 크게 향상됩니다. (기본적으로 비대칭 공개 키는 저장할 수 없으며 개인 키만 저장하면 되지만 암호화 및 복호화 프로세스가 느리고 대칭 암호화, 동일한 키의 암호화 및 복호화, 키 저장이 어렵지만 암호화 해독 프로세스가 빠르고 모든 장점이 보완됩니다)

그림 2)

이미지 3)

디지털 서명은 어떻게 문서의 신뢰성을 보장하고 내가 서명한 사람을 확인합니까?

비대칭 암호화를 예로 들면, 서명 문제를 통해 우리는 서명이 주로 개인키의 공개키로 구성되어 있고, 이 두 가지로부터 디지털 서명이 생성된다는 것을 알 수 있습니다. 내가 서명한 파일은 어떻습니까? 예를 들어 저는 지금 Xiao Ming이고 RSA 비대칭 서명 알고리즘을 통해 공개 키와 개인 키를 생성했는데, 내 신원을 확인할 수 있는 파일(또는 중요한 파일)을 전달해야 하는데 일반 텍스트 파일이 아니기 때문에 변조되기 쉬우므로 먼저 해시 연산을 사용하여 증명 파일을 파일 해시 값으로 변환합니다. base64와 달리 해시 연산의 결과는 되돌릴 수 없습니다. 즉, 결과에서 원본 텍스트를 추론할 수 없습니다. 구체적인 이유는 자세히 다루지 않았습니다. 다음은 몇 가지 예입니다. 비가역성의 간단한 예는 모듈러 산술임을 대략적으로 보여주는 예입니다. 예를 들어 10%3을 사용할 수 있습니다. 결과는 1이지만 10은 4 등이 될 수도 있기 때문에 1에서 추론할 수 없기 때문에 해쉬 연산 역시 비슷한 방식으로 더 복잡할 수 있지만 원리는 동일합니다. 그림 (1)과 같이 파일의 해시 값을 얻은 다음 서명 알고리즘에 의해 생성된 개인 키를 사용하여 파일의 해시 값 H를 암호화한 다음 디지털 서명 S를 얻습니다. , 원본 파일 및 디지털 서명은 일반 텍스트로 인터넷에 보낼 수 있습니다. 예를 들어, 이때 Xiaohong은 서명을 확인하고 Xiaoming 및 파일의 진위 여부를 확인해야 하며 그런 다음 디지털 서명만 해독하면 됩니다. S는 공개 키를 통해 파일을 얻습니다. 해시 값 H, 그는 또한 파일을 파일 해시 값 H로 해시한 다음 생성된 해시 값 H를 두 번 비교할 수 있습니다. 일치하지 않으면 파일에 오류가 있음을 의미합니다. 디지털 서명은 Xiao Ming의 것이 아니므로 비교가 실패합니다. 그러나 디지털 서명의 메커니즘으로 인해 디지털 서명은 개인 키 소유자만 생성할 수 있습니다. , 따라서 디지털 서명은 개인 키 소유자가 생성해야 합니다. 아마도 Xiao Ming이 파일 소유자에 속하지 않는다고 말할 수 있지만 디지털 서명은 Xiao Ming에 속해야 하지만 여기서 또 다른 주의점이 있습니다. .Xiao Ming이 개인 키의 소유자인지 어떻게 확인할 수 있나요? 그림(2)와 같이 다른 사람도 전자서명을 통해 공개키와 개인키를 생성한 후 자신의 공개키와 개인키를 이용해 검증할 수 있는데, 그 과정에 따르면 이것도 가능하다. San's 입학 통지서가 학교에 전달되고 Zhang San의 이름으로 서명된 경우에도 확인을 통과할 수 있습니다. 왜냐하면 내가 Zhang San인지 확인할 수 없고 개인 키의 소유자가 누구인지 알 수 없기 때문입니다. Xiao Ming, 하지만 우리는 알고 있습니다 사람이 개인 키를 생성하면 공개 키도 생성됩니다. 열쇠는 샤오밍인가? 이를 통해 그림(3)과 같은 디지털 인증서가 탄생하게 되는데, 디지털 인증서는 권위 있는 기관이자 인증서 발급기관으로서, 공개키의 생성자가 누구인지, 즉 인증서를 발행한 주체가 누구인지를 증명하는 역할을 한다. 개인 키의 소유자는 다음과 같습니다. 따라서 모든 사람은 사칭을 피하기 위해 권한 있는 장소로 이동하면 됩니다. 마찬가지로 인증서 발급 구조에도 자체 공개 키와 개인 키 세트가 있습니다. Xiao Ming은 자신의 정보와 공개 키를 다음으로 보냅니다. CA 인증서 발급 기관 CA 그것이 맞는지 확인한 후 Xiao Ming의 신원 정보와 공개 키는 그의 개인 키를 사용하여 암호화되고 유명 CA의 인증을 받게 되므로 Xiao Ming이 인증서를 넣을 때 신뢰성을 갖게 됩니다. 인터넷, 즉 학교가 학생에게 주는 졸업증명서에 학교 인장이 찍히게 되어 회사에 가져갈 때 다른 사람들이 보면 학력을 믿고 믿게 됩니다. 봉인.그러나, CA 인증서가 위조되지 않도록 하려면 어떻게 해야 할까요? 그림(4)와 같이 무심코 도장을 찍고 정규학교인 척하는 꿩대학이 있을 수 있고, 그 다음에는 국가교육국 등 상위 검증기관이 있어야 한다. 잘 모르면 무리), 컴퓨터의 경우에는 시스템에 루트 인증서가 미리 설치되어 있기 때문에 루트 인증서는 해당 CA 기관이 신뢰할 수 있는지 확인하는 역할을 합니다.

그림 4)