node 에서 jwt 를 사용 하여 생 성 된 token 은 어디 에 존재 해 야 합 니까?

답:보통 클 라 이언 트 에 저 장 됩 니 다.
jwt 즉 JSON Web Token 은 인증 프로 토 콜 로 요청 한 신분 정보 와 신분 권한 을 검증 하 는 데 사 용 됩 니 다.
아침 에 어 딘 가 를 돌아 다 닐 때 한 친구 가 이 질문 을 하 는데 jwt 의 저장 위치 가 궁금 합 니 다.마침 얼마 전에 이 내용 을 배우 고 있 었 는데 초대 하지 않 고 뻔뻔 하 게 대답 했다.
처음에 나 도 이 token 을 어떻게 저장 하 는 지 궁금 했다.그리고 하마터면 redis 저장 소 를 만 들 뻔 했다.
나중에 자 료 를 찾 아 보 니 이 token 은 서버 에서 저장 하지 않 아 도 된다 는 것 을 알 게 되 었 다.클 라 이언 트 가 잘 저장 하면 됩 니 다.어떤 유지 방식 이 든 지,심지어 사용자 에 게 쪽 지 를 써 서 주머니 에 넣 으 라 고 해도 됩 니 다!
그럼 이 토 큰 은 어떻게 일 하 는 거 예요?
먼저 서버 에 저장 해 야 할 동작,즉 전통 적 인 session 세 션 세 션 방법 을 말씀 드 리 겠 습 니 다.
먼저 사용자 로그 인 을 하려 면 서버 에서 로그 인 표를 유지 해 야 합 니 다.이 로그 인 표 는 캐 시 에 넣 을 수도 있 고 데이터베이스 에 넣 을 수도 있 습 니 다.
사용자 가 로그 인 할 때 사용자 정 보 를 이 로그 인 표 에 기록 한 다음 에 로그 인 id,즉 session 을 내 보 냅 니 다.이 session 을 고객 에 게 되 돌려 주 고 클 라 이언 트 가 다음 에 이 정 보 를 가 져 오 라 고 요청 하도록 합 니 다.
전단 의 어린 친구 들 에 게 이 과정 은 감지 되 지 않 습 니 다.백 엔 드 의 형 들 은 set-cookie 라 는 http 헤드 필드 를 사용 하여 브 라 우 저 쿠키 에 데 이 터 를 기록 합 니 다.그리고 요청 할 때 브 라 우 저 는 쿠키 를 요청 머리 에 직접 씁 니 다.
클 라 이언 트 가 서버 에 들 어 오 라 고 요청 할 때 서버 는 쿠키 에 있 는 session 을 받 은 다음 에 로그 인 표 에서 사용자 정 보 를 찾 고 사용자 권한 을 검증 한 다음 에 정상 적 인 업무 상호작용 을 완성 할 수 있 습 니 다.
에이,그럼 지금 나 는 여러 가지 난잡 한 이유 로 로그 인 표를 지 키 고 싶 지 않 아.어떻게 해 야 할 지 생각해 봐.
간단 하 다.사용자 정 보 를 클 라 이언 트 에 게 직접 보 내 고 클 라 이언 트 가 매번 사용자 정 보 를 가 져 오 게 한다.이렇게 요청 하면 표 도 찾 지 않 고 어떤 사용자 가 요청 하 는 지 직접 알 수 있다.
그러나 이렇게 해서 사용자 의 정보 가 모두 폭로 되 었 습 니 다.그 중개인 들 은 이런 강직 한 요 구 를 가장 좋아 합 니 다.그들 은 직접 의 자 를 가지 고 서버 포트 에 앉 아서 며칠 동안 앉 아 있 으 면 데이터 베이스 에 있 는 온 집안 의 오래된 시 계 는 다른 사람 에 게 밝 혀 집 니 다.
이러 면 틀림없이 안 되 는데,그럼 어 떡 하지?
비밀 을 넣 고 헷 갈 리 게 하 세 요.그러면 형 들 이 당신 의 token 을 받 게 됩 니 다.잠시 동안 어 리 석 은 표정 을 짓 게 될 것 입 니 다.아마 확률 이 털털 하 게 갈 것 입 니 다.일부 준비(KPI)만 남 겨 두 고 온 형 이 애 써 해결 을 찾 고 있 을 것 입 니 다.
그리고 서버 에서 비밀 을 풀 면 사용자 정 보 를 얻 을 수 있 습 니 다.마찬가지 로 기한 이 지난 시간 도 비밀문서 에 쓰 고 기한 이 지나 면 401 번 로그 인 페이지 를 뛰 어 넘 습 니 다.이렇게 되면 백 엔 드 에 로그 인 증명 서 를 저장 하지 않 아 도 되 는 방안 이 나온다.
이것 이 바로 jwt 의 가장 기본 적 인 작업 원리 이다.바로 신분 정 보 를 클 라 이언 트 에 맡 기 는 것 이다.
jwt 에서 생 성 된 token 은 header,payload,signature 세 부분 으로 구성 되 어 있 으 며,이 세 부분 은 소수점"."로 구분 되 어 있 습 니 다.
header,즉 머리 정보 입 니 다.이 token 의 기본 정 보 를 묘사 하 는 제 이 슨 형식 입 니 다.

{
    "alg":"HS256",
    "typ":"JWT"
}

alg 는 뒤쪽 signature 서명 부분의 생 성 암호 화 알고리즘 을 대표 하 며,typ 는 이 token 이 jwt 형식 임 을 나타 낸다.
payload,바로 당신 의 사용자 데이터 이자 json 형식 입 니 다.그러나 jwt 는 민감 한 데 이 터 를 안에 넣 는 것 을 권장 하지 않 습 니 다.규범 상 payload 는 header 와 마찬가지 로 base 64 인 코딩 을 한 번 만 한 후에 token 에 표시 하기 때 문 입 니 다.
signature 는 이 token 의 서명 입 니 다.보통 앞의 header 와 payload 에 자신 이 정의 한 비밀 키 문자열 을 암호 화하 여 만 든 문자열 입 니 다.
앞에서 말 했 듯 이 jwt 는 payload 의 내용 을 base 64 인 코딩 으로 한 번 만 하기 때문에 공격 자 형 들 이 당신 의 내용 을 바 꾸 는 것 은 매우 간단 합 니 다.그러나 형 들 은 당신 의 비밀 키 를 모 릅 니 다.바 꾼 후에 정확 한 서명 을 만 들 수 없습니다.암호 화 된 방식 으로 요청 한 header.payload 를 다시 검사 한 결과 signature 와 맞지 않 습 니 다.이 럴 때 누군가가 일 을 하고 있다 는 것 을 잘 알 수 있 고 500 척 의 서버 로 돌아 가 끊 었 다.
더 안전 하려 면 https 프로 토 콜 을 사용 하여 요청 통신 을 하 는 것 을 권장 합 니 다.
물론,당신 은 이미 이 작업 원 리 를 알 고 있 습 니 다.스스로 더러 운 사람의 규범 을 만 들 었 습 니 다.안 되 는 것 도 아 닙 니 다.예 를 들 어 payload 를 다시 한 번 비밀 로 한 다음 에 gzip 아래 등 입 니 다.
그럼 jwt 를 사용 하 는 장점 은 무엇 입 니까?
첫째,서버 에서 로그 인 표를 유지 할 필요 가 없고 공간 을 절약 할 필요 가 없다.특히 사용자 가 많은 경우.
두 번 째,확장 이 간단 하 다.전 제 는 당신 이 일 을 하지 않 고 성실 하 게 json 형식 으로 당신 의 내용 을 표현 하 는 것 이다.
세 번 째,상태 가 없 으 면 서버 에서 분석 을 지원 하면 업 무 를 전개 할 수 있 습 니 다.세 션 을 공유 하 는 체 제 를 따로 만 들 지 않 아 도 기 계 를 추가 할 수 있 습 니 다.
네 번 째,다양한 클 라 이언 트 를 지원 하고 쿠키 를 지원 하지 않 아 도 놀 수 있 습 니 다.
나 쁜 점 은 요 구 를 할 때마다 이 데 이 터 를 가 져 가 는 것 이 고 요청 내용 이 추 가 된 것 이 분명 합 니 다.그리고 들 어 오 라 고 요청 할 때마다 header 와 paylaod 를 가 져 와 서 비밀 과 signature 검 사 를 한 번 더 하면 요청 한 처리 시간 이 늘 어 납 니 다.이것 은 전통 적 인 조작 에 비해 사실은 시간 과 공간 간 의 저울질 문제 이 고 마지막 으로 네가 선택 하 는 것 에 달 려 있다.
여기 서 node 가 jwt 를 사용 하여 생 성 된 token 이 어디 에 존재 해 야 하 는 지 에 관 한 글 을 소개 합 니 다.jwt 가 생 성 한 token 이 어디 에 저장 되 는 지 에 관 한 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 찾 아 보 세 요.앞으로 많은 응원 부 탁 드 리 겠 습 니 다!