역사 각 요청은 요청과 응답이 합쳐진 새로운 HTTP 프로토콜입니다. 특히 방금 HTTP 요청을 보낸 사람이 누구인지 기억할 필요가 없기 때문입니다. 매우 흥미로운 시간입니다.
2. 하지만 온라인 쇼핑 웹사이트, 로그인이 필요한 웹사이트 등 대화형 웹 애플리케이션이 증가하면서 우리는 즉시 문제에 직면하게 됩니다. 즉, 세션을 관리하려면 시스템에 로그인한 사람이 누구인지 기억해야 합니다. 장바구니에 항목을 넣으려면 각 사람을 구별해야 합니다. HTTP 요청은 상태 비저장이므로 제가 생각해낸 해결책은 모든 사람에게 세션 ID를 보내는 것입니다. , 직설적으로 말하면 이는 임의의 문자열이며 모든 사람이 나에게 HTTP 요청을 보낼 때마다 이 문자열을 나와 함께 보내면 누가 누구인지 구분할 수 있습니다. 그런데 모두가 매우 만족하지만 서버는 만족하지 않습니다. 모두가 자신의 세션 ID만 저장하면 되고, 서버는 모든 사람의 세션 ID를 저장해야 합니다. 액세스 서버가 너무 많으면 수천, 심지어 수십만 개가 될 것입니다. 이것은 서버에 큰 오버헤드이며 서버의 확장 기능을 심각하게 제한합니다. 예를 들어 두 대의 컴퓨터를 사용하여 클러스터를 형성하고 Little F가 컴퓨터 A를 통해 시스템에 로그인하면 세션 ID가 저장됩니다. 기계 A., Little F의 다음 요청이 기계 B로 전달된다면 어떻게 될까요? 머신 B에는 작은 F라는 세션 ID가 없습니다. 때때로 약간의 트릭이 사용됩니다. 즉, 세션 고정입니다. 이는 Little F의 요청이 항상 기계 A에 붙어 있지만 이것이 작동하지 않는다는 것을 의미합니다. 기계 A가 끊기면 기계 B로 전송되어야 합니다. 그런 다음 세션을 복사해야 합니다. 두 컴퓨터 간에 세션 ID를 이동하는 것은 거의 힘듭니다.나중에 Memcached라는 사람이 트릭을 생각해 냈습니다. 세션 ID를 한 곳에 중앙에 저장하면 모든 컴퓨터가 이 위치의 데이터에 액세스하게 됩니다. 이런 방식으로 복사할 필요는 없지만 추가됩니다. 단일 실패 지점 세션을 담당하는 시스템이 중단되면 모든 사람이 다시 로그인해야 하며 아마도 혼나서 죽을 가능성이 있습니다.
저 역시 신뢰성을 높이기 위해 이 단일 머신을 클러스터로 묶어두려고 했지만, 어찌됐든 이 작은 세션이 저에게는 큰 부담이 되었습니다.
4. 그래서 어떤 사람들은 왜 이 지독한 세션을 저장해야 합니까? 각 클라이언트마다 저장하도록 하면 얼마나 좋을까요? 
관련 권장 사항: "
Python Video Tutorial"
Token의 데이터는 일반 텍스트로 저장되며(인코딩에 Base64를 사용하지만 암호화되지 않음) 다른 사람이 계속 볼 수 있으므로 비밀번호와 같은 민감한 정보를 저장할 수 없습니다.
물론, 누군가의 토큰을 다른 사람이 훔쳐간 경우에는 내가 할 수 있는 일이 없습니다. 이는 도둑이 합법적인 사용자라고 생각하는 것이기도 합니다.
이런 식으로 세션 ID를 저장하지 않고 토큰을 생성한 다음 토큰을 확인하여 세션 저장 공간을 얻습니다.
세션 ID에 대한 부담이 덜해졌습니다. 이제 사용자의 방문 횟수가 늘어나면 머신을 직접 추가해도 됩니다. 이 무국적 느낌이 너무 좋아요!
Cookie
쿠키는 브라우저에 영구적으로 저장될 수 있는 일종의 데이터를 의미합니다. 브라우저에서 구현하는 데이터 저장 기능일 뿐입니다.
쿠키는 서버에 의해 생성되어 브라우저로 전송됩니다. 브라우저는 쿠키를 특정 디렉터리의 텍스트 파일에 kv 형식으로 저장합니다. 이 쿠키는 다음에 동일한 웹사이트가 요청될 때 서버로 전송됩니다. 쿠키는 클라이언트에 저장되기 때문에 쿠키가 악의적으로 사용되지 않고 디스크 공간을 너무 많이 차지하지 않도록 브라우저에서 몇 가지 제한 사항을 추가했기 때문에 각 도메인의 쿠키 수가 제한됩니다.
Session
session은 말 그대로 세션을 의미합니다. 이는 누군가와 대화할 때와 비슷합니다. 대화하고 있는 사람이 Li Si가 아니라 Zhang San이라는 것을 어떻게 알 수 있습니까? 상대방은 자신이 Zhang San임을 나타내는 특정 특성(외모 등)을 가지고 있어야 합니다.
세션도 비슷합니다. 서버는 현재 자신에게 요청을 보내는 사람이 누구인지 알아야 합니다. 이러한 구별을 위해 서버는 각 클라이언트에 서로 다른 "신원 식별자"를 할당합니다. 그런 다음 클라이언트가 서버에 요청을 보낼 때마다 이 "신원 식별자"를 가져오고 서버는 요청이 있음을 알게 됩니다. 누구에게서 왔는지. 클라이언트가 이 "ID"를 저장하는 방법은 여러 가지가 있습니다. 브라우저 클라이언트의 경우 기본적으로 모든 사람이 쿠키를 사용합니다.
서버는 사용자의 정보를 일시적으로 서버에 저장하기 위해 세션을 사용합니다. 사용자가 웹사이트를 떠난 후 세션은 파기됩니다. 이 사용자 정보 저장 방법은 쿠키보다 안전하지만 세션에 결함이 있습니다. 웹 서버가 로드 밸런싱된 경우 다음 작업 요청이 다른 서버로 이동하면 세션이 손실됩니다.
Token
토큰 기반 인증은 웹 분야 어디에서나 볼 수 있습니다. Web API를 사용하는 대부분의 인터넷 회사에서 토큰은 여러 사용자에 대한 인증을 처리하는 가장 좋은 방법입니다.
다음 기능을 사용하면 프로그램에서 토큰 기반 인증을 사용할 수 있습니다.
(1) 상태 비저장 및 확장 가능
(2) 모바일 장치 지원
(3) 프로그램 간 호출
(4) 보안
토큰 기반 인증을 사용하는 대기업들은 여러분이 본 대부분의 API와 웹 애플리케이션이 토큰을 사용합니다. 예를 들어 Facebook, Twitter, Google+, GitHub 등이 있습니다.
The Origin of Token
토큰 기반 인증의 원리와 장점을 소개하기 전에, 기존 인증 방식을 살펴보는 것이 좋을 것 같습니다.
서버 기반 인증
우리 모두는 HTTP 프로토콜이 상태 비저장이라는 것을 알고 있습니다. 이러한 상태 비저장은 프로그램이 클라이언트의 신원을 식별하기 위해 각 요청을 확인해야 함을 의미합니다.
이전에 프로그램은 서버에 저장된 로그인 정보를 통해 요청을 식별했습니다. 이 방법은 일반적으로 세션을 저장하여 수행됩니다.
웹, 애플리케이션, 모바일 단말기의 등장으로 이러한 검증 방식은 점차 문제점을 드러내고 있습니다. 특히 확장성에 있어서는 더욱 그렇습니다.
서버 인증 방법에 따라 노출되는 일부 문제
(1) 세션: 인증된 사용자가 요청을 시작할 때마다 서버는 정보를 저장하기 위한 레코드를 생성해야 합니다. 점점 더 많은 사용자가 요청을 보내면 메모리 오버헤드가 계속 증가합니다.
(2) 확장성: 세션을 사용하여 서버 메모리에 로그인 정보를 저장하면 확장성 문제가 발생합니다.
(3) CORS(Cross-Origin Resource Sharing): 여러 모바일 장치에서 데이터를 사용해야 하는 경우 도메인 간 리소스를 공유하는 것이 골치 아픈 일이 될 수 있습니다. Ajax를 사용하여 다른 도메인의 리소스를 크롤링하는 경우 요청이 금지될 수 있습니다.
(4) CSRF(교차 사이트 요청 위조): 사용자가 은행 웹사이트를 방문하면 교차 사이트 요청 위조 공격에 취약하며 이를 악용하여 다른 웹사이트에 액세스할 수 있습니다.
이러한 문제 중에서 확장성이 가장 두드러집니다. 그러므로 우리는 좀 더 효과적인 방법을 찾아야 합니다.
토큰 기반 인증 원칙
토큰 기반 인증은 상태 비저장이므로 서버나 세션에 사용자 정보를 저장하지 않습니다.
이 개념은 서버 측에 정보를 저장할 때 많은 문제를 해결합니다.
NoSession은 사용자가 로그인했는지 여부에 대해 걱정하지 않고 필요에 따라 프로그램이 컴퓨터를 추가하거나 제거할 수 있음을 의미합니다.
토큰 기반 인증 과정은 다음과 같습니다.
(1) 사용자는 사용자 이름과 비밀번호를 통해 요청을 보냅니다.
(2) 프로그램 검증.
(3) 프로그램은 서명된 토큰을 클라이언트에 반환합니다.
(4) 클라이언트는 토큰을 저장하고 각 요청에 사용합니다.
(5) 서버는 토큰을 확인하고 데이터를 반환합니다.
모든 요청에는 토큰이 필요합니다. HTTP 요청이 상태 비저장인지 확인하려면 토큰을 HTTP 헤더에 전송해야 합니다. 또한 서버가 모든 도메인의 요청을 수락할 수 있도록 서버 속성 Access-Control-Allow-Origin:*을 설정했습니다.
ACAO 헤더에 *를 표시(지정)하는 경우 HTTP 인증, 클라이언트 SSL 인증서, 쿠키 등의 인증서가 포함되어서는 안 된다는 점에 유의하세요.
구현 아이디어:
(1) 사용자 로그인 확인이 성공적으로 완료되면 토큰이 클라이언트에 반환됩니다.
(2) 클라이언트는 데이터를 수신한 후 클라이언트에 저장합니다.
(3) 클라이언트는 API에 액세스할 때마다 토큰을 서버로 전달합니다.
(4) 서버 측은 필터 필터 검증을 사용합니다. 검증에 성공하면 요청 데이터가 반환되고, 검증에 실패하면 오류 코드가 반환됩니다. 프로그램에서 정보를 인증하고 토큰을 얻은 후에는 이 토큰으로 많은 작업을 수행할 수 있습니다. 권한 기반 토큰을 생성하여 이를 제3자 애플리케이션에 전달하여 데이터를 얻을 수도 있습니다(허용되는 특정 토큰을 통해서만).
토큰의 장점
상태 비저장 및 확장 가능
클라이언트에 저장된 토큰은 상태 비저장이며 확장이 가능합니다. 이러한 무상태 및 세션 정보 저장 없음을 기반으로 로드 밸런서는 사용자 정보를 한 서비스에서 다른 서버로 전송할 수 있습니다.
인증된 사용자의 정보를 세션에 저장하면 각 요청마다 사용자는 인증된 서버에 인증 정보를 보내야 합니다(세션 선호도라고 함). 이용자 수가 많을 경우 다소 혼잡이 발생할 수 있습니다.
하지만 서두르지 마세요. 토큰을 사용하면 토큰 자체가 사용자의 확인 정보를 보유하므로 이러한 문제는 쉽게 해결됩니다.
Security
쿠키 대신 요청에 토큰을 보내면 CSRF(교차 사이트 요청 위조)를 방지할 수 있습니다. 쿠키가 클라이언트 측에서 토큰을 저장하는 데 사용되더라도 쿠키는 저장 메커니즘일 뿐이며 인증에는 사용되지 않습니다. Session에 정보를 저장하지 않으면 더 적은 세션을 운영할 수 있습니다.
토큰은 시간이 제한되어 있으므로 사용자는 일정 기간 후에 다시 인증해야 합니다. 토큰이 자동으로 만료될 때까지 반드시 기다릴 필요는 없습니다. 토큰 철회를 통해 동일한 인증을 가진 특정 토큰 또는 토큰 그룹이 무효화될 수 있습니다.
Extensibility
토큰을 사용하면 다른 프로그램과 권한을 공유하는 프로그램을 만들 수 있습니다. 예를 들어, 임의의 소셜 계정을 자신의 계정(Fackbook 또는 Twitter)과 연결할 수 있습니다. 서비스를 통해 Twitter에 로그인할 때(이 프로세스를 버퍼링할 예정임) 이러한 버퍼를 Twitter 데이터 스트림에 연결할 수 있습니다(Buffer가 Twitter 스트림에 게시하도록 허용함).
토큰을 사용할 때 타사 애플리케이션에 선택적 권한을 제공할 수 있습니다. 사용자가 다른 애플리케이션에서 자신의 데이터에 액세스하기를 원하는 경우 자체 API를 구축하여 특별 권한 토큰을 파생할 수 있습니다.
멀티 플랫폼 크로스 도메인
CORS(Cross-domain Resource Sharing)에 대해 미리 이야기해 보겠습니다. 애플리케이션과 서비스를 확장하려면 다양한 디바이스와 애플리케이션이 참여해야 합니다.
Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.
사용자가 확인된 토큰을 가지고 있는 한 모든 도메인에서 데이터와 리소스를 요청할 수 있습니다.
Access-Control-Allow-Origin: *
표준에 따라 토큰을 생성할 때 몇 가지 옵션을 설정할 수 있습니다. 후속 기사에서 이에 대해 더 자세히 설명하겠지만 표준 사용법은 JSON 웹 토큰에 반영됩니다.
JSON 웹 토큰에 대한 최신 프로그램과 문서가 제공됩니다. 다양한 언어를 지원합니다. 이는 나중에 인증 메커니즘을 실제로 전환할 수 있음을 의미합니다.
위 내용은 하나의 글로 쿠키, 세션, 토큰에 대한 철저한 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
