ＡA시스템과 B시스템은 앞부분과 뒷부분이 분리되어 있습니다.
(두 시스템교차 도메인)
이제 시스템 A의 페이지가 시스템 B로 이동합니다.
이제 이를 사용하여 시스템 B로 이동합니다. 주소 표시줄에 암호화된 토큰(사용자 ID 포함)이 있어 자동으로 로그인할 수 있도록 도와줍니다.
이 페이지에는 해당 사용자에 대한 제품 정보와 할인이 표시됩니다.
내가 이때 다른 사람의 토큰을 알고 있다고 가정하고, 주소 표시줄을 수정해 보세요. 해당 페이지는 다른 사람의 정보가 됩니다.
이때 타인의 계정비밀번호도 몰랐는데, 그러다가 타인의 사용자정보를 일부 알게 되었습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
https를 암호화합니다. HTTP 프로토콜 자체는 안전하지 않으며 일반 텍스트입니다.
이 사람들 말이 맞고, 나는 틀렸어
가장 간단한 방법이 더 안전한 방법이기도 합니다. 스테이션 b가 로그인을 도와주면 상자가 다시 나타납니다. 비밀번호를 확인하게 해주세요!
csrf 또는이라는 토큰이 있습니다. 난수 방식. 가질만한 가치가 있습니다. csrf 토큰은 이러한 도메인 간 공격을 제한합니다
JWT 인증 토큰을 헤더에 배치해야 합니다. 인증 인증을 고려해 보세요
먼저 토큰의 출현은 사용자 인증 문제를 해결하기 위한 것입니다. 두 가지 시스템이 있으므로 자동 로그인은 매우 안전하지 않습니다.
그러나 그러한 필요성이 있으므로 가능한 한 이를 피하려고 노력할 수 있습니다. 해결책은 다음과 같습니다. 둘째, 교차 시스템 토큰을 승인할 때 이 토큰의 인증을 설정하십시오. 일회성으로 토큰의 유효성을 압축하기 위해 토큰은 30분 동안만 유효합니다. 실제로 Weibo 및 기타 승인된 토큰과 같은 많은 타사 로그인에는 30분만 포함되어 있다는 사실을 참고할 수 있습니다. 닉네임, 아바타 등 소량의 정보입니다.
실제 장면인가요?
다른 사람의 토큰을 얻을 수 있다면 그의 비밀번호를 도청하는 것과 같습니다. 이는 JWT 보안 문제가 아닙니다.
JWT 자체와 관련된 조치는 만료 시간을 추가하여 일정 기간이 지나면 JWT가 강제로 만료되도록 하는 것입니다.
JWT 사양에 따르면 JWT를 URL이 아닌 요청 헤더 Authorization에 넣는 것이 가장 좋습니다.
HTTPS가 작동합니다.