일반인의 관점에서 말하면 현재 사용자의 신원을 확인하여 "당신 자신"임을 증명하는 것을 의미합니다(예: 매일 출근 및 퇴근할 때, 지문으로 입력해야 하며, 지문이 시스템에 입력한 지문과 일치하면 체크인에 성공합니다.)
인터넷 인증:
사용자 이름과 비밀번호로 로그인
다음으로 로그인 링크 보내기 이메일
인증 코드를 받을 휴대폰 번호
이메일을 받을 수 있는 한/ 인증 코드는 기본적으로 계정의 소유자임을 의미합니다
인증이란 무엇입니까
사용자가 부여합니다 타사 애플리케이션에서 사용자의 특정 리소스에 액세스할 수 있는 권한
모바일 애플리케이션, APP를 설치할 때 권한 부여(사진 앨범, 지리적 위치 등에 대한 액세스)를 허용할지 묻는 메시지가 표시됩니다. WeChat 애플릿에 접속하면 로그인 시 애플릿에서 권한 부여(닉네임, 아바타, 지역, 성별 등의 개인 정보 획득)가 허용되는지 여부를 묻는 메시지가 표시됩니다.
권한을 얻는 방법은 다음과 같습니다. , session, token, OAuth
자격증명이란 무엇입니까?
인증 및 승인을 구현하기 위한 전제 조건
은 액세스를 표시하기 위해 미디어(인증서)가 필요하다는 것입니다. 개인의 신원전국 시대 시대에 상양(Shang Yang)은 개혁을 수행하고 사진 촬영 포스트를 발명했습니다. 사진 스티커는 정부에서 발행하는 것으로 매끄럽고 곱게 광택이 나는 대나무판에 소지자의 프로필 사진과 출생지가 새겨져 있습니다. 중국인이 이를 소유해야 하며, 그렇지 않으면 비밀 요원이나 간첩으로 간주됩니다.
실생활에서 모든 사람은 소유자의 신원을 증명하는 데 사용되는 법적 문서인 전용 주민등록증을 갖게 됩니다. 신분증을 통해 휴대폰카드/은행카드/개인대출/교통카드 등을 신청할 수 있는
인증서입니다.
인터넷 애플리케이션에서 일반 웹사이트(예: Nuggets)에는 게스트 모드와 로그인 모드의 두 가지 모드가 있습니다. 게스트 모드에서는 웹사이트의 기사를 정상적으로 열람할 수 있습니다. 기사를 좋아요/수집/공유하려면 로그인하거나 계정을 등록해야 합니다. 사용자가 성공적으로 로그인하면 서버는 사용자가 사용하는 브라우저에 토큰을 발행합니다. 이 토큰은 브라우저가 요청을 보낼 때마다 이 토큰을 가져오며 사용할 수 있습니다. 게스트 모드에서는 사용할 수 없는 기능입니다.
쿠키란 무엇입니까
HTTP는 상태 비저장 프로토콜입니다(트랜잭션 처리를 위한 메모리가 없으며 클라이언트와 서버 세션이 완료될 때마다 서버는 세션 정보를 저장하지 않습니다
). 각 요청은 완전히 서버는 현재 방문자의 신원 정보를 확인할 수 없으며, 지난 요청의 발송인과 이번 요청의 발송인이 동일인인지도 알 수 없습니다. 따라서 세션을 추적하려면(누가 나를 방문하는지 알기 위해) 서버와 브라우저가 적극적으로 상태를 유지해야 합니다. 이 상태는 이전과 이후의 두 요청이 동일한 브라우저에서 온 것인지 서버에 알리는 데 사용됩니다. 이 상태는 쿠키나 세션을 통해 달성되어야 합니다.
쿠키는 클라이언트 측에 저장됩니다.
쿠키는 서버에서 사용자의 브라우저로 전송되고 로컬에 저장되는 작은 데이터 조각으로, 다음에 브라우저가 요청할 때 서버로 전송됩니다. 같은 서버.
쿠키는 도메인 간이 아닙니다.
각 쿠키는 단일 도메인 이름에 바인딩되며 다른 도메인 이름에서 사용할 수 없습니다. 1단계 도메인 이름과 2단계 도메인 이름 간의 공유는 허용됩니다(신뢰할 수 있음) 도메인입니다).
쿠키 중요 속성
Attribute
Description
name=value
키-값 쌍, 쿠키 이름 및 해당 값은 문자열 유형 이어야 합니다. 값이 유니코드 문자인 경우 , 문자 인코딩이 필요합니다. - 값이 바이너리 데이터인 경우 BASE64 인코딩이 필요합니다.
쿠키가 만료되는 시간(초)입니다. 정수인 경우 쿠키는 maxAge 초 후에 만료됩니다. 음수인 경우 쿠키는 임시 쿠키이며 브라우저를 닫으면 만료되며 브라우저는 쿠키를 어떤 형태로든 저장하지 않습니다. 0이면 쿠키를 삭제합니다. 기본값은 -1입니다. - 만료되는 것보다 사용하기 더 쉽습니다.
expires
만료 시간, 쿠키는 설정된 특정 시점 이후에 만료됩니다. 일반 브라우저 쿠키는 기본적으로 저장됩니다. 세션을 종료하기 위해 브라우저를 닫으면 쿠키가 삭제됩니다
secure
쿠키가 보안 프로토콜을 통해서만 전송되는지 여부. 보안 프로토콜에는 데이터를 네트워크에서 전송하기 전에 암호화하는 HTTPS, SSL 등이 포함됩니다. 기본값은 거짓입니다. secure 값이 true인 경우 쿠키는 HTTP에서는 유효하지 않으며 HTTPS에서만 유효합니다.
httpOnly
쿠키에 httpOnly 속성이 설정된 경우 JS 스크립트를 통해 쿠키 정보를 읽을 수 없지만 쿠키는 여전히 애플리케이션을 통해 수동으로 수정할 수 있으므로 XSS 공격을 예방하는 것은 절대적으로 안전하지 않습니다
사용자가 처음으로 서버를 요청하면 서버는 사용자가 제출한 관련 정보를 기반으로 해당 세션을 생성합니다. 요청이 반환되면 이 세션의 고유 식별 정보인 SessionID가 브라우저에 반환됩니다. 브라우저는 서버에서 반환된 SessionID 정보를 수신한 후 이 정보를 쿠키에 저장합니다. 동시에 쿠키는 이 SessionID가 속한 도메인 이름을 기록합니다.
사용자가 서버를 두 번째로 방문하면, 요청은 이 도메인 이름에 쿠키 정보가 있는지 자동으로 확인합니다. 쿠키 정보가 있으면 서버는 쿠키에서 SessionID를 얻은 다음 SessionID를 기반으로 해당 Session을 찾습니다. 정보가 발견되지 않으면 사용자가 로그인하지 않았거나 로그인이 유효하지 않음을 의미합니다. Session이 발견되면 사용자가 로그인했음을 증명하며 다음 작업을 수행할 수 있습니다.
위 과정에 따르면
SessionID는 Cookie와 Session
을 연결하는 가교 역할을 합니다. 대부분의 시스템에서도 이 원칙을 사용하여 사용자 로그인 상태를 확인합니다.
관련 주제 추천:
php 세션 세션(주제)
쿠키와 세션의 차이점
보안: 세션은 쿠키보다 더 안전합니다. 세션은 서버 측에 저장되고 쿠키는 클라이언트 측에 저장됩니다.
다양한 유형의 액세스 값: 쿠키는 문자열 데이터 저장만 지원합니다. 다른 유형의 데이터를 설정하려면 세션에서 모든 데이터 유형을 저장할 수 있도록 변환해야 합니다.
다른 유효 기간: 우리가 자주 사용하는 기본 로그인 기능과 같이 쿠키는 일반적으로 만료 시간이 짧고 클라이언트가 닫히면 만료되도록 설정할 수 있습니다(기본적으로). 또는 세션 시간이 초과되었습니다.
다양한 저장 크기: 단일 쿠키로 저장되는 데이터는 4K를 초과할 수 없습니다. 세션은 쿠키보다 훨씬 많은 데이터를 저장할 수 있지만, 방문 횟수가 너무 많으면 너무 많은 서버 리소스를 차지하게 됩니다.
토큰이란 무엇입니까
Acesss 토큰
리소스 인터페이스(API)에 액세스하는 데 필요한 리소스 자격 증명
간단한 토큰의 구성: uid(사용자의 고유 ID), 시간(타임스탬프) 현재 시간), 서명(서명, 토큰의 첫 번째 숫자는 해시 알고리즘을 사용하여 특정 길이의 16진수 문자열로 압축됩니다)
서버는 요청을 받은 다음 클라이언트 요청에 포함된 토큰을 확인합니다. 확인에 성공하면 요청한 데이터를 클라이언트에 반환합니다
모든 요청은 토큰을 전달해야 하며 토큰은 HTTP 헤더에 배치되어야 합니다.
토큰 기반 사용자 인증은 서버 측 상태 비저장 인증 방법이므로 서버는 토큰 데이터를 저장할 필요가 없습니다. 토큰을 파싱하는 컴퓨팅 시간을 세션의 저장 공간으로 교환함으로써 서버에 대한 부담을 줄이고 빈번한 데이터베이스 쿼리를 줄입니다. 토큰은 애플리케이션에서 완전히 관리되므로 동일한 원본 새로 고침 정책을 피할 수 있습니다.
또 다른 종류의 토큰——새로고침 토큰
새로 고침 토큰은 액세스 토큰을 새로 고치는 데 특별히 사용되는 토큰입니다. 새로 고침 토큰이 없으면 액세스 토큰도 새로 고칠 수 있지만 새로 고칠 때마다 사용자가 로그인 사용자 이름과 비밀번호를 입력해야 하므로 매우 번거롭습니다. 새로 고침 토큰을 사용하면 사용자가 추가 작업을 수행하지 않고도 클라이언트가 새로 고침 토큰을 직접 사용하여 액세스 토큰을 업데이트할 수 있습니다.
액세스 토큰은 유효 기간이 비교적 짧습니다. 만료로 인해 액세스 토큰이 무효화되면 새로 고침 토큰도 만료되어 사용자는 새로 토큰을 얻을 수 있습니다. 다시 로그인하세요.
새로 고침 토큰과 만료 시간은 서버의 데이터베이스에 저장되며 새 액세스 토큰을 신청할 때만 확인됩니다. 이는 비즈니스 인터페이스의 응답 시간에 영향을 미치지 않으며 세션처럼 메모리에 보관할 필요가 없습니다. 요청이 많습니다.
토큰과 세션의 차이점
세션은 서버와 클라이언트의 세션 상태를 기록하여 서버를 상태 저장하고 세션 정보를 기록할 수 있게 만드는 메커니즘입니다. 그리고 토큰은 리소스 인터페이스(API)에 액세스하는 데 필요한 리소스 자격 증명인 토큰입니다. 토큰 은 서버를 상태 비저장으로 만들고 세션 정보를 저장하지 않습니다.
세션과 토큰은 모순되지 않습니다. 각 요청이 서명되어 모니터링 및 재생 공격을 방지할 수 있는 반면 세션은 통신 보안을 보장하기 위해 링크 계층에 의존해야 하기 때문에 보안이 세션보다 좋습니다.
상태 저장 세션을 구현해야 하는 경우 세션을 추가하여 서버 측에 일부 상태를 저장할 수 있습니다.
소위 세션 인증은 SessionID를 예측할 수 없기 때문에 사용자 정보를 Session에 저장하는 것뿐이므로 당분간은 안전한 것으로 간주됩니다. 그리고 Token은 OAuth Token 또는 이와 유사한 메커니즘을 의미하는 경우 인증 및 권한 부여를 제공합니다. 인증은 사용자를 위한 것이고 승인은 앱을 위한 것입니다. 목적은 앱에 사용자 정보에 접근할 수 있는 권한을 부여하는 것입니다. 여기의 토큰은 독특합니다. 다른 앱이나 다른 사용자에게 전송할 수 없습니다. Session은 간단한 인증만을 제공합니다. 즉, 이 SessionID가 있는 한 이 사용자는 모든 권한을 갖는 것으로 간주됩니다. 이 데이터는 엄격하게 기밀로 유지되어야 하며 사이트에만 저장되어야 하며 다른 웹사이트나 타사 앱과 공유해서는 안 됩니다. 간단히 말하면:
사용자 데이터를 제3자와 공유해야 하거나 제3자가 API 인터페이스를 호출하도록 허용해야 하는 경우 토큰을 사용하세요. 항상 자신의 웹사이트와 앱만 있다면 무엇을 사용하든 상관없습니다.
JWT란 무엇입니까
JSON 웹 토큰(줄여서 JWT)은 현재 가장 인기 있는
교차 도메인 인증 솔루션입니다.
은
인증 및 승인 메커니즘입니다.
JWT는 웹 애플리케이션 환경 간
클레임 전달을 위해 구현된 JSON 기반 개방형 표준(RFC 7519)입니다. JWT 클레임은 일반적으로 리소스 서버에서 리소스를 얻기 위해 ID 공급자와 서비스 공급자 간에 인증된 사용자 ID 정보를 전달하는 데 사용됩니다. 예를 들어 사용자 로그인에 사용됩니다.
HMAC 알고리즘이나 RSA 공개/개인 키를 사용하여 JWT에 서명할 수 있습니다. 디지털 서명이 있기 때문에 전송된 정보는 신뢰할 수 있습니다.
Yuan Yifeng 선생님의 JSON 웹 토큰 입문 튜토리얼은 매우 이해하기 쉽기 때문에 여기에서는 자세한 내용을 다루지 않겠습니다.
Generate JWTjwt.io/
www.jsonwebtoken.io/
JWT의 원칙
JWT 인증 프로세스:
사용자는 사용자 이름/비밀번호를 입력하여 로그인합니다. 서버 인증이 성공하면 JWT가 클라이언트에 반환됩니다.
클라이언트가 저장합니다. 토큰을 로컬에서 사용합니다(일반적으로 로컬 저장소를 사용하고 쿠키도 사용할 수 있습니다)
사용자가 보호된 경로나 리소스에 액세스하려면 Bearer 모드를 사용하여 요청 헤더의 Authorization 필드에 JWT를 추가해야 합니다. 다음과 같습니다
Authorization: Bearer <token>复制代码</token>
서버 측 보호 경로는 요청 헤더 Authorization에서 JWT 정보를 확인합니다. 합법적인 경우 사용자의 동작이 허용됩니다.
JWT는 자체 포함되어 있기 때문입니다(일부 세션이 포함되어 있음). 정보), 데이터베이스 쿼리 필요성이 줄어듭니다
JWT는 쿠키를 사용하지 않기 때문에 CORS(Cross-Domain Resource Sharing)에 대한 걱정 없이 어떤 도메인 이름을 사용하여 API 서비스를 제공할 수 있습니다.
사용자 상태가 no이기 때문에 상태 비저장 인증 메커니즘
JWT 사용 방법
클라이언트는 서버에서 반환한 JWT를 수신하며, 쿠키 또는 localStorage에 저장할 수 있습니다.
사용자가 보호된 경로나 리소스에 액세스하려는 경우 이를 쿠키에 넣어 자동으로 보낼 수 있습니다. 그러나 이는 도메인을 넘나들 수 없으므로 HTTP 요청의 Authorization 필드에 넣는 것이 더 좋습니다. 헤더 패턴을 사용하여 JWT를 추가합니다.
GET /calendar/v1/events
Host: api.example.com
Authorization: Bearer <token>复制代码</token>
사용자의 상태는 서버의 메모리에 저장되지 않습니다. 이는 상태 비저장 인증 메커니즘
서버의 보호된 라우팅은 요청의 Authorization 헤더에서 JWT 정보를 확인하고, 이것이 합법적인 경우 사용자에게 행동이 허용됩니다.
JWT는 독립적이므로 데이터베이스 쿼리 필요성이 줄어듭니다.
JWT의 이러한 기능을 사용하면 상태 비저장 특성에 전적으로 의존하여 데이터 API 서비스를 제공하거나 다운로드 스트리밍 서비스를 만들 수도 있습니다.
JWT는 쿠키를 사용하지 않기 때문에 도메인 간 리소스 공유에 대한 걱정(CORS)
방법 2
교차 도메인의 경우 , POST 요청의 데이터 본문에 JWT를 넣을 수 있습니다.
방법 3
URL을 통해 전송
http://www.example.com/user?token=xxx复制代码
프로젝트에서 JWT 사용
프로젝트 주소
Token과 JWT
동일: 토큰
둘 다 가능 사용자 정보 기록
둘 다 서버를 무상태로 만듭니다
성공적인 확인 후에만 클라이언트는 서버의 보호된 리소스에 액세스할 수 있습니다
차이:
토큰: 서버는 클라이언트가 보낸 토큰을 확인할 때 데이터베이스에 쿼리하여 사용자 정보를 얻은 다음 토큰이 유효한지 확인해야 합니다.
JWT: 토큰과 페이로드는 암호화되어 클라이언트에 저장됩니다. 서버는 확인을 위해 키를 사용하기만 하면 됩니다(확인은 JWT 자체에서도 구현됩니다). , JWT는 사용자 정보와 암호화된 데이터를 모두 포함하고 있기 때문입니다.
일반적인 프런트엔드 및 백엔드 인증 방법
Session-Cookie
토큰 확인(JWT, SSO 포함)
OAuth2.0(개방 인증)
일반적인 암호화 알고리즘
해시 알고리즘, 해시 함수 A 해시 기능은 모든 종류의 데이터로부터 작은 디지털 "지문"을 생성하는 방법입니다. 해시 알고리즘은 데이터를 다시 섞어 새로운 해시 값을 생성합니다.
해시 알고리즘은 주로 데이터 신뢰성(즉, 무결성)을 보장하는 데 사용됩니다. 즉, 보낸 사람은 원본 메시지와 해시 값을 함께 보내고, 받는 사람은 동일한 해시 함수를 사용하여 원본 데이터가 진짜인지 확인합니다.
해시 알고리즘은 일반적으로 다음과 같은 특징을 가지고 있습니다.
빠른 것과 마찬가지로 원본 데이터는 해시 값을 빠르게 계산할 수 있습니다.
역 난이도: 해시 값을 통해 원본 데이터를 추론하는 것은 기본적으로 불가능합니다.
입력 민감성: 원본 데이터 약간의 변화만 있어도 얻어지는 해시 값은 매우 다릅니다
충돌 회피: 동일한 해시 값을 얻기 위해 다른 원본 데이터를 찾는 것은 어렵습니다. 우주의 원자 수는 대략 10에서 10 사이입니다. 따라서 2의 256승은 모든 가능성을 수용할 수 있는 충분한 공간을 갖습니다. 알고리즘이 좋으면 충돌 확률은 매우 낮습니다.
2의 128승은 340282366920938463463374607431768211456입니다. 39번째 거듭제곱 수준
2의 256번째 거듭제곱은 1.1579208923731619542357098입니다. 500869 × 10의 77승은 10의 77승입니다.
위 내용은 보장할 수 없습니다. 데이터가 악의적으로 변조된 경우 원본 데이터와 해시 값이 모두 악의적으로 변조될 수 있습니다. 변조되지 않았는지 확인하려면 RSA 공개 키를 사용하고 해시 값과 결합된 개인 키 체계입니다.
해시 알고리즘은 주로 컴퓨터 전송 중 오류를 방지하기 위해 사용됩니다. 초기 컴퓨터는 이를 보호하기 위해 데이터의 처음 7비트와 8번째 비트 패리티 검사 코드를 사용했습니다(데이터 조각의 경우 12.5%의 낭비 효율성이 낮습니다). 또는 파일, 해싱을 통해 알고리즘은 128비트 또는 256비트 해시 값을 생성합니다. 검증에 문제가 있는 경우 재전송이 필요합니다.
FAQ
쿠키 사용 시 고려해야 할 사항
클라이언트 측에 저장되기 때문에 클라이언트 측에서 쉽게 변조할 수 있으므로 사용 전 적법성 확인이 필요합니다
민감한 데이터는 저장하지 마세요. 사용자 비밀번호, 계정 잔액
보안을 어느 정도 향상하려면 httpOnly를 사용하세요.
저장할 수 있는 데이터의 양은 4kb를 초과할 수 없습니다.
데이터를 줄이려면 올바른 도메인과 경로를 설정하세요.
쿠키는 도메인 간을 이동할 수 없습니다.
한 개의 브라우저는 최대 20개의 쿠키를 저장할 수 있으며, 브라우저는 일반적으로 300개의 쿠키만 허용하며, 쿠키를 기반으로 세션을 구현해야 합니다. , 따라서 토큰은 모바일 단말기에서 일반적으로 사용됩니다. 세션을 사용할 때 고려해야 할 문제
서버의 저장 세션 동시에 온라인에 많은 사용자가 있는 경우 이러한 세션은 더 많은 메모리를 차지합니다. 서버 측에서 정기적으로 정리해야 합니다
웹사이트에서
클러스터를 배포
할 때 여러 웹 서버 간에 세션을 공유하는 방법에 대한 문제에 직면하게 됩니다. 세션은 단일 서버에서 생성되지만 사용자 요청을 처리하는 서버가 반드시 세션을 생성한 서버일 필요는 없기 때문에 서버는 이전에 세션에 입력된 로그인 자격 증명과 같은 정보를 얻을 수 없습니다.
여러 애플리케이션이 세션을 공유하려는 경우 위의 문제 외에도 교차 도메인 문제도 발생합니다. 서로 다른 애플리케이션이 서로 다른 호스트에 배포될 수 있고 교차 도메인 쿠키 처리가 각 애플리케이션에서 수행되어야 하기 때문입니다.
sessionId는 쿠키에 저장됩니다. 브라우저가 쿠키를 금지하거나 지원하지 않으면 어떻게 되나요? 일반적으로 sessionId 뒤에 url 매개변수가 따라와서 URL을 다시 작성하므로 반드시 쿠키로 세션을 구현할 필요는 없습니다.
모바일 단말기는 쿠키를 잘 지원하지 않으며 세션을 쿠키 기반으로 구현해야 합니다. 쿠키에 포함되어 있으므로 모바일 단말에서는 토큰을 많이 사용합니다
토큰 사용 시 고려할 사항
토큰을 데이터베이스에 저장하면 쿼리 시간이 너무 오래 걸린다고 생각되면 저장하도록 선택하면 됩니다. 기억 속에. 예를 들어, redis는 토큰 쿼리 요구 사항에 매우 적합합니다.
토큰은 애플리케이션에 의해 완전히 관리되므로 동일 출처 정책을 피할 수 있습니다.
토큰은 CSRF 공격을 피할 수 있습니다(쿠키가 더 이상 필요하지 않기 때문에)
모바일 단말기는 쿠키를 잘 지원하지 않습니다. 쿠키를 기반으로 토큰은 모바일 단말에서 흔히 사용됩니다
JWT 사용 시 고려해야 할 사항
JWT는 쿠키에 의존하지 않기 때문에 어떤 도메인 이름을 사용해도 걱정 없이 API 서비스를 제공할 수 있습니다. CORS(교차 도메인 리소스 공유 문제) 정보
JWT는 기본적으로 암호화되지 않지만 암호화될 수도 있습니다. 원본 토큰이 생성된 후 키를 사용하여 다시 암호화할 수 있습니다.
JWT 비밀 데이터는 암호화 없이 JWT에 쓸 수 없습니다.
JWT는 인증뿐만 아니라 정보 교환에도 사용될 수 있습니다. JWT를 효과적으로 사용하면 서버가 데이터베이스를 쿼리하는 횟수를 줄일 수 있습니다.
JWT의 가장 큰 장점은 더 이상 서버에 Session을 저장할 필요가 없어 서버 인증 및 인증 사업을 쉽게 확장할 수 있다는 점입니다. 하지만 이는 JWT의 가장 큰 단점이기도 합니다. 서버가 세션 상태를 저장할 필요가 없기 때문에 사용 중에 토큰을 삭제하거나 토큰의 권한을 변경할 수 없습니다. 즉, JWT가 발행되면 서버가 추가 로직을 배포하지 않는 한 만료될 때까지 항상 유효합니다.
JWT 자체에는 인증 정보가 포함되어 있으며, 일단 유출되면 누구나 토큰에 대한 모든 권한을 얻을 수 있습니다. 도난을 줄이기 위해서는 JWT의 유효기간을 상대적으로 짧게 설정해야 한다. 더 중요한 일부 권한의 경우 사용자가 해당 권한을 사용할 때 다시 인증을 받아야 합니다.
JWT는 일회성 명령 인증에 적합합니다. 유효 기간이 매우 짧은 JWT가 발급됩니다. 위험이 노출되더라도 작업마다 새로운 JWT가 생성되므로 위험이 매우 적습니다. JWT를 저장하여 진정으로 무국적을 달성합니다.
도용을 줄이기 위해 JWT는 HTTP 프로토콜을 사용하여 일반 코드로 전송해서는 안 되며, HTTPS 프로토콜을 사용하여 전송해야 합니다.
암호화 알고리즘을 사용할 때 고려해야 할 사항
비밀번호를 일반 텍스트
절대 해싱 알고리즘을 사용하여 비밀번호를 처리하고, Base64 또는 기타 인코딩 방법을 사용하여 비밀번호를 저장하지 마세요. 이는 비밀번호를 저장하는 것과 같습니다. 일반 텍스트로 비밀번호를 저장하는 것도 동일합니다. 인코딩 대신 해싱을 사용하세요 . 인코딩과 암호화는 양방향 프로세스인 반면, 비밀번호는 기밀이므로 소유자에게만 알려야 합니다. 이 프로세스는 단방향이어야 합니다. 이를 위해 해싱이 사용됩니다. 해시를 디코딩하는 것과 같은 일은 없지만 인코딩이 있으면 디코딩이 있고 암호화가 있으면 해독이 있습니다.
MD5 또는 SHA1과 같은 약하거나 손상된 해싱 알고리즘을 사용하지 말고 강력한 비밀번호 해싱 알고리즘만 사용하세요.
비밀번호 소유자에게라도 비밀번호를 일반 텍스트로 표시하거나 보내지 마세요. "비밀번호 찾기" 기능이 필요한 경우 새로운 일회성(중요) 비밀번호를 무작위로 생성하고 이 비밀번호를 사용자에게 보낼 수 있습니다.
분산 아키텍처 하의 세션 공유 솔루션
1. 세션 복제
어떤 서버의 세션이 변경(추가, 삭제, 수정)되면 노드는 세션의 모든 내용을 직렬화한 후 다른 모든 서버에 브로드캐스팅합니다. 다른 서버에 세션이 필요한지 여부에 관계없이 세션 동기화를 보장하기 위해 노드를 사용하세요
장점: 내결함성, 서버 간 세션이 실시간으로 응답할 수 있습니다. 단점: 세션 수가 많으면 네트워크 정체가 발생하고 서버 성능이 저하될 수 있습니다.
2. 고정 세션/IP 바인딩 전략
Ngnix의 ip_hash 메커니즘을 채택하여 특정 IP에 대한 모든 요청을 동일한 서버로 전달합니다. 즉, 사용자를 서버에 바인딩합니다. 사용자가 처음 요청하면 로드 밸런서는 사용자의 요청을 서버 A로 전달합니다. 로드 밸런서가 고정 세션을 설정하면 사용자의 모든 후속 요청은 서버 A로 전달됩니다. 사용자와 서버 A. 서버 A가 서로 붙어 있습니다. 이것이 고정 세션 메커니즘입니다.
장점: 간단하며 세션에 대한 처리를 수행할 필요가 없습니다. 단점: 내결함성 부족. 현재 액세스한 서버에 장애가 발생하여 사용자가 두 번째 서버로 이동하면 해당 세션 정보가 유효하지 않습니다. 적용 가능한 시나리오: 오류는 고객에게 작은 영향을 미칩니다. 서버 오류는 확률이 낮은 이벤트입니다.
. 구현 방법: Nginx를 예로 들면, 업스트림 모듈에서 ip_hash 속성을 구성하여 고정 세션을 달성할 수 있습니다.
3. 세션 공유(일반적으로 사용)
Memcached, Redis 등 분산 캐싱 솔루션을 사용하여 세션을 캐시하지만 Memcached 또는 Redis는 클러스터여야 합니다.
아키텍처가 복잡해지더라도 세션을 Redis에 저장합니다. , 그리고 Redis에 한 번 더 액세스해야 하지만 이 솔루션의 이점도 큽니다.
세션 공유를 실현합니다.
수평으로 확장할 수 있습니다(Redis 서버 추가).
서버가 연결되어도 세션이 손실되지 않습니다. 다시 시작됩니다(그러나 Redis의 세션 새로 고침/무효화 메커니즘에도 주의하세요).
서버 세션 전체에서 공유될 수 있을 뿐만 아니라 플랫폼(예: 웹 페이지 및 앱)에서도 공유될 수 있습니다.
4. 세션 지속성
세션의 지속성을 보장하기 위해 세션을 데이터베이스에 저장
장점:서버에 문제가 있어도 세션이 손실되지 않습니다 단점: 웹 사이트의 방문 횟수가 많기 때문에 세션을 데이터베이스에 저장하면 데이터베이스 압력에 많은 피해가 발생하고 데이터베이스를 유지하려면 추가 오버헤드가 필요합니다.
브라우저만 닫으면 세션이 정말 사라지나요?
그건 옳지 않아요. 세션의 경우 프로그램이 서버에 세션 삭제를 알리지 않는 한 서버는 일반적으로 사용자가 로그오프할 때 세션을 삭제하라는 명령을 보냅니다. 그러나 브라우저는 서버가 닫히기 전에 서버가 닫힐 것임을 적극적으로 알리지 않으므로 서버는 브라우저가 닫혔음을 알 기회가 없습니다. 이러한 착각이 일어나는 이유는 대부분의 세션 메커니즘이 세션 쿠키를 사용하여 데이터를 저장하기 때문입니다. 세션 ID이며, 브라우저를 닫으면 세션 ID가 사라지며, 서버에 다시 연결하면 원래 세션을 찾을 수 없습니다. 서버가 설정한 쿠키가 하드디스크에 저장되거나, 브라우저가 보낸 HTTP 요청 헤더를 다시 작성하여 원래 세션 ID를 서버로 보내는 어떤 방법을 사용하는 경우, 브라우저가 실행 중일 때 원래 세션을 계속 열 수 있습니다. 다시 열었습니다. 정확합니다브라우저를 닫아도 세션이 삭제되지 않으므로 클라이언트가 세션을 마지막으로 사용한 이후의 시간이 이 만료 시간을 초과하면 서버는 강제로 세션 만료 시간을 설정합니다. 클라이언트가 활동을 중지하면 저장 공간을 절약하기 위해 세션이 삭제됩니다.
프로젝트 주소
프로젝트에서 JWT 사용하기
Postscript
이 글은 백엔드/알고리즘 지식이 별로 없어서 제가 이해한 것을 바탕으로 한 이론적 지식만 이야기한 것입니다. 틀린 점이 있으면 알려주세요. 정말 감사합니다
