JSON 웹 토큰 무효화

JSON 웹 토큰 무효화

---

내가 작업하고있는 새로운 node.js 프로젝트의 경우 쿠키 기반 세션 접근 방식에서 전환하는 것에 대해 생각하고 있습니다 (즉, 사용자 브라우저에 사용자 세션을 포함하는 키 값 저장소에 ID를 저장하는 것을 의미합니다) JSON 웹 토큰 (jwt)을 사용하여 토큰 기반 세션 접근 방식 (키-값 저장소 없음)

이 프로젝트는 socket.io를 사용하는 게임입니다. 토큰 기반 세션을 갖는 것은 단일 세션 (web 및 socket.io)에 여러 통신 채널이있는 시나리오에서 유용합니다.

jwt 접근 방식을 사용하여 서버에서 토큰 / 세션 무효화를 어떻게 제공합니까?

또한 이런 종류의 패러다임에서 어떤 일반적인 (또는 드문) 함정 / 공격을 찾아야하는지 이해하고 싶었습니다. 예를 들어이 패러다임이 세션 저장소 / 쿠키 기반 접근 방식과 동일하거나 다른 종류의 공격에 취약한 경우.

그래서, 다음 (에서 적응이 있다고 이 와 이 ) :

세션 저장소 로그인 :

app.get('/login', function(request, response) {
    var user = {username: request.body.username, password: request.body.password };
    // Validate somehow
    validate(user, function(isValid, profile) {
        // Create session token
        var token= createSessionToken();

        // Add to a key-value database
        KeyValueStore.add({token: {userid: profile.id, expiresInMinutes: 60}});

        // The client should save this session token in a cookie
        response.json({sessionToken: token});
    });
}

토큰 기반 로그인 :

var jwt = require('jsonwebtoken');
app.get('/login', function(request, response) {
    var user = {username: request.body.username, password: request.body.password };
    // Validate somehow
    validate(user, function(isValid, profile) {
        var token = jwt.sign(profile, 'My Super Secret', {expiresInMinutes: 60});
        response.json({token: token});
    });
}

-

세션 저장소 접근 방식에 대한 로그 아웃 (또는 무효화)을 위해서는 지정된 토큰으로 KeyValueStore 데이터베이스를 업데이트해야합니다.

토큰 자체에는 일반적으로 키-값 저장소에 존재하는 정보가 포함되므로 이러한 메커니즘은 토큰 기반 접근 방식에 존재하지 않는 것 같습니다.

---

나도이 질문을 연구 해 왔으며 아래의 아이디어 중 완전한 해결책은 없지만 다른 사람들이 아이디어를 배제하거나 다른 아이디어를 제공하는 데 도움이 될 수 있습니다.

1) 단순히 클라이언트에서 토큰을 제거하십시오

분명히 이것은 서버 측 보안에는 아무런 영향을 미치지 않지만 토큰이 존재하지 않도록하여 공격자를 막을 수 있습니다 (즉, 로그 아웃하기 전에 토큰을 도난 했어야 함).

2) 토큰 블랙리스트 생성

초기 만료 날짜까지 유효하지 않은 토큰을 저장하고 들어오는 요청과 비교할 수 있습니다. 모든 요청에 ​​대해 데이터베이스를 터치해야하기 때문에 처음부터 완전히 토큰을 사용해야하는 이유를 무효화하는 것처럼 보입니다. 로그 아웃과 만료 시간 사이에있는 토큰 만 저장하면되기 때문에 스토리지 크기는 더 작아 질 수 있습니다 (이것은 직감이며 컨텍스트에 따라 달라집니다).

3) 토큰 만기 시간을 짧게 유지하고 자주 회전하십시오.

토큰 만료 시간을 충분히 짧은 간격으로 유지하고 실행중인 클라이언트가 추적을 유지하고 필요한 경우 업데이트를 요청하면 1 번은 완전한 로그 아웃 시스템으로 효과적으로 작동합니다. 이 방법의 문제점은 클라이언트 코드가 닫히는 사이 (만료 간격을 설정하는 시간에 따라) 사용자가 로그인 상태를 유지할 수 없다는 것입니다.

비상시 계획

응급 상황이 발생했거나 사용자 토큰이 손상된 경우 사용자가 로그인 자격 증명으로 기본 사용자 조회 ID를 변경할 수 있습니다. 연관된 사용자를 더 이상 찾을 수 없으므로 모든 연관된 토큰이 유효하지 않게됩니다.

또한 마지막 로그인 날짜를 토큰과 함께 포함시키는 것이 좋습니다. 따라서 먼 시간이 지난 후에 다시 로그인 할 수 있습니다.

토큰을 사용한 공격과의 유사점 / 차이점에서이 게시물은 다음과 같은 질문을 해결합니다. http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/

---

위에 게시 된 아이디어는 훌륭하지만 기존 JWT를 모두 무효화하는 매우 간단하고 쉬운 방법은 단순히 비밀을 변경하는 것입니다.

서버가 JWT를 작성하고 비밀 (JWS)로 서명 한 후이를 클라이언트로 전송하면, 단순히 비밀을 변경하면 기존 토큰이 모두 무효화되고 모든 사용자가 이전 토큰이 갑자기 유효하지 않아 인증을 위해 새 토큰을 얻도록 요구합니다. 서버에.

실제 토큰 내용 (또는 조회 ID)을 수정하지 않아도됩니다.

명백하게 이것은 토큰 만료마다 위의 솔루션 중 하나가 필요한 경우 (예 : 토큰 만료 시간이 짧거나 토큰 내부에 저장된 키 무효화) 기존의 모든 토큰이 만료되기를 원하는 긴급 상황에서만 작동합니다.

---

이것은 @mattway의 답변을 뒷받침하고 지원하는 긴 의견입니다.

주어진:

이 페이지에서 제안 된 다른 솔루션 중 일부는 모든 요청에 ​​대해 데이터 스토어에 도달하는 것을 옹호합니다. 모든 인증 요청의 유효성을 검사하기 위해 기본 데이터 저장소에 도달하면 다른 기존 토큰 인증 메커니즘 대신 JWT를 사용해야 할 이유가 줄어 듭니다. 매번 데이터 저장소에 갈 경우 상태 비 저장 대신 JWT를 기본적으로 상태 저장으로 설정했습니다.

(사이트에 많은 양의 무단 요청이 수신되는 경우 JWT는 데이터 스토어에 도달하지 않고 요청을 거부합니다. 이는 도움이됩니다. 다른 유스 케이스도있을 수 있습니다.)

주어진:

상태 비 저장 JWT 에는 다음과 같은 중요한 사용 사례에 대한 즉각 적이고 안전한 지원 을 제공 할 수있는 방법이 없기 때문에 일반적인 실제 웹 앱에 대한 상태 비 저장 JWT 인증을 얻을 수 없습니다 .

사용자 계정이 삭제 / 차단 / 일시 중지되었습니다.

사용자 비밀번호가 변경되었습니다.

사용자의 역할 또는 권한이 변경되었습니다.

관리자가 사용자를 로그 아웃했습니다.

JWT 토큰의 다른 응용 프로그램 중요 데이터는 사이트 관리자가 변경합니다.

이 경우 토큰 만료를 기다릴 수 없습니다. 토큰 무효화는 즉시 발생해야합니다. 또한 악의적 인 의도가 있든 없든 클라이언트가 이전 토큰의 사본을 보관 및 사용하지 않도록 신뢰할 수 없습니다.

따라서 @ matt-way # 2 TokenBlackList의 답변이 JWT 기반 인증에 필요한 상태를 추가하는 가장 효율적인 방법이라고 생각합니다.

만료 날짜에 도달 할 때까지이 토큰을 보유하는 블랙리스트가 있습니다. 토큰 목록은 총 사용자 수에 비해 상당히 적습니다. 만료 될 때까지 블랙리스트에 올린 토큰 만 유지하면되기 때문입니다. 무효화 된 토큰을 redis, memcached 또는 키의 만료 시간 설정을 지원하는 다른 메모리 내 데이터 저장소에 넣어 구현합니다.

초기 JWT 인증을 통과하는 모든 인증 요청에 대해 인 메모리 DB를 계속 호출해야하지만 전체 사용자 세트에 대한 키를 저장할 필요는 없습니다. 특정 사이트에 큰 영향을 줄 수도 있고 아닐 수도 있습니다.

---

사용자 모델에 jwt 버전 번호를 기록합니다. 새로운 jwt 토큰은 버전을 이것으로 설정합니다.

jwt의 유효성을 검사 할 때 사용자의 현재 jwt 버전과 버전 번호가 동일한 지 확인하십시오.

이전 jwt를 무효화하려면 언제든지 사용자 jwt 버전 번호를 충돌 시키십시오.

---

아직 시도하지 않았으며 다른 답변 중 일부를 기반으로 많은 정보를 사용합니다. 여기서 복잡한 점은 사용자 정보 요청 당 서버 측 데이터 저장소 호출을 피하는 것입니다. 다른 솔루션의 대부분은 사용자 세션 저장소에 대한 요청 당 db 조회가 필요합니다. 특정 시나리오에서는 문제가되지 않지만 이러한 호출을 피하고 필요한 서버 측 상태를 매우 작게 만들기 위해 만들어졌습니다. 모든 강제 무효화 기능을 제공하기 위해 서버 측 세션을 다시 작성하지만 소규모입니다. 그러나 당신이 그것을하고 싶다면 여기 요점이 있습니다 :

목표 :

• 데이터 저장소 사용을 완화하십시오 (상태 비 저장).
• 모든 사용자를 강제로 로그 아웃하는 기능
• 언제든지 개인을 강제로 로그 아웃하는 기능.
• 일정 시간이 지나면 암호를 다시 입력해야합니다.
• 여러 클라이언트와 작업 할 수있는 기능
• 사용자가 특정 클라이언트에서 로그 아웃을 클릭하면 강제로 다시 로그인 할 수 있습니다. (사용자가 자리를 비운 후 누군가가 클라이언트 토큰을 "삭제 취소"하지 못하게하려면 추가 정보에 대한 설명을 참조하십시오)

해결책:

• 수명이 길고 (몇 시간) 클라이언트에 저장된 새로 고침 토큰과 쌍으로 된 단명 (5m 미만) 액세스 토큰을 사용하십시오 .
• 모든 요청은 인증 또는 새로 고침 토큰 만료 날짜를 확인합니다.
• 액세스 토큰이 만료되면 클라이언트는 새로 고침 토큰을 사용하여 액세스 토큰을 새로 고칩니다.
• 새로 고침 토큰 확인 중에 서버는 작은 사용자 목록 블랙리스트를 확인합니다 (발견 된 경우 새로 고침 요청 거부).
• 클라이언트에 유효한 (만료되지 않은) 새로 고침 또는 인증 토큰이없는 경우 다른 모든 요청이 거부되므로 사용자는 다시 로그인해야합니다.
• 로그인 요청시 사용자 데이터 저장소에서 금지 여부를 확인하십시오.
• 로그 아웃시-해당 사용자를 세션 블랙리스트에 추가하여 다시 로그인해야합니다. 다중 디바이스 환경에서 모든 디바이스에서 로그 아웃하지 않도록 추가 정보를 저장해야하지만 디바이스 필드를 디바이스에 추가하여 수행 할 수 있습니다. 사용자 블랙리스트.
• x 시간 후에 다시 입력을하려면 인증 토큰에서 마지막 로그인 날짜를 유지하고 요청 당 확인하십시오.
• 모든 사용자를 강제로 로그 아웃하려면 토큰 해시 키를 재설정하십시오.

사용자 테이블에 금지 된 사용자 정보가 있다고 가정하면 서버에서 블랙리스트 (상태)를 유지해야합니다. 잘못된 세션 블랙리스트-사용자 ID 목록입니다. 이 블랙리스트는 새로 고침 토큰 요청 중에 만 확인됩니다. 새로 고침 토큰 TTL 인 한 항목을 계속 사용해야합니다. 새로 고침 토큰이 만료되면 사용자는 다시 로그인해야합니다.

단점 :

• 새로 고침 토큰 요청에서 데이터 저장소 조회를 수행해야합니다.
• 액세스 토큰의 TTL에 유효하지 않은 토큰이 계속 작동 할 수 있습니다.

장점 :

• 원하는 기능을 제공합니다.
• 정상 작동 상태에서는 토큰 새로 고침 작업이 사용자에게 표시되지 않습니다.
• 모든 요청 대신 새로 고침 요청에 대한 데이터 저장소 조회 만 수행하면됩니다. 즉, 초당 1이 아닌 15 분마다 1이됩니다.
• 서버 측 상태를 매우 작은 블랙리스트로 최소화합니다.

이 솔루션을 사용하면 서버가 15 분마다 DB 호출 만하 기 때문에 사용자 정보에는 적어도 reddis와 같은 메모리 데이터 저장소가 필요하지 않습니다. reddis를 사용하는 경우 유효 / 유효하지 않은 세션 목록을 저장하면 매우 빠르고 간단한 솔루션이됩니다. 새로 고침 토큰이 필요 없습니다. 각 인증 토큰에는 세션 ID와 장치 ID가 있으며 생성시 reddis 테이블에 저장 될 수 있으며 적절할 때 무효화 될 수 있습니다. 그런 다음 모든 요청에서 확인되고 유효하지 않은 경우 거부됩니다.

---

내가 고려한 접근법은 항상 iatJWT에 (발행 된) 값을 갖는 것입니다. 그런 다음 사용자가 로그 아웃하면 해당 타임 스탬프를 사용자 레코드에 저장하십시오. JWT를 검증 할 때는 iat마지막으로 로그 아웃 한 타임 스탬프와 비교하십시오 . iat이전 버전 인 경우 유효하지 않습니다. 예, DB로 가야하지만 JWT가 유효하면 항상 사용자 레코드를 가져옵니다.

내가 볼 수있는 주요 단점은 여러 브라우저에 있거나 모바일 클라이언트가있는 경우 모든 세션에서 로그 아웃한다는 것입니다.

이것은 또한 시스템의 모든 JWT를 무효화하는 훌륭한 메커니즘이 될 수 있습니다. 확인의 일부는 마지막 유효 iat시간 의 글로벌 타임 스탬프에 대한 것일 수 있습니다 .

---

나는 조금 늦었지만 괜찮은 해결책이 있다고 생각합니다.

데이터베이스에 비밀번호가 마지막으로 변경된 날짜와 시간을 저장하는 "last_password_change"열이 있습니다. 또한 JWT에 발행 날짜 / 시간을 저장합니다. 토큰의 유효성을 검사 할 때 토큰이 발급 된 후 비밀번호가 변경되었는지, 아직 만료되지 않았더라도 토큰이 거부되었는지 확인합니다.

---

사용자 문서 / 레코드의 DB에 "last_key_used"필드가있을 수 있습니다.

사용자가 사용자로 로그인하여 전달하면 새 임의 문자열을 생성하고 last_key_used 필드에 저장 한 후 토큰에 서명 할 때 페이로드에 추가하십시오.

사용자가 토큰을 사용하여 로그인 할 때 DB의 last_key_used를 확인하여 토큰의 토큰과 일치하는지 확인하십시오.

그런 다음 사용자가 예를 들어 로그 아웃하거나 토큰을 무효화하려는 경우 해당 "last_key_used"필드를 다른 임의의 값으로 변경하면 후속 검사가 실패하므로 사용자가 사용자로 로그인하여 다시 전달해야합니다.

---

왜 jti 클레임을 사용하고 (목록에) 사용자 레코드 필드로 목록에 저장하지 않습니까 (DB에 따라 다르지만 최소한 쉼표로 구분 된 목록은 괜찮습니다)? 다른 사람들이 어쨌든 사용자 레코드를 얻고 싶다고 지적 했으므로 별도의 조회가 필요하지 않으므로이 방법을 사용하면 다른 클라이언트 인스턴스에 대해 여러 개의 유효한 토큰을 가질 수 있습니다 ( "로그 아웃 어디서나"목록을 비워 둘 수 있음)

---

1. 토큰에 1 일의 만료 시간을 제공하십시오
2. 일일 블랙리스트를 유지하십시오.
3. 무효화 된 / 로그 아웃 토큰을 블랙리스트에 넣습니다.

토큰 유효성 검사의 경우 먼저 토큰 만료 시간을 확인한 다음 토큰이 만료되지 않은 경우 블랙리스트를 확인하십시오.

긴 세션 요구를 위해서는 토큰 만료 시간을 연장하기위한 메커니즘이 있어야합니다.

---

파티에 늦게, 약간의 연구 끝에 내 두 센트가 아래에 주어집니다. 로그 아웃하는 동안 다음과 같은 일이 발생하는지 확인하십시오.

클라이언트 스토리지 / 세션 지우기

로그인 또는 로그 아웃이 발생할 때마다 사용자 테이블의 마지막 로그인 날짜-시간 및 로그 아웃 날짜-시간을 업데이트하십시오. 따라서 로그인 날짜 시간은 항상 로그 아웃보다 커야합니다 (또는 현재 상태가 로그인 상태이고 아직 로그 아웃되지 않은 경우 로그 아웃 날짜를 널로 유지)

블랙리스트 추가 테이블을 유지하고 정기적으로 제거하는 것보다 훨씬 간단합니다. 여러 장치를 지원하려면 OS 또는 클라이언트 세부 정보와 같은 몇 가지 추가 세부 정보가있는 로그 아웃 날짜 및 로그 아웃을 유지하기 위해 추가 테이블이 필요합니다.

---

이와 같은 메모리 내 목록 유지

user_id   revoke_tokens_issued_before
-------------------------------------
123       2018-07-02T15:55:33
567       2018-07-01T12:34:21

토큰이 일주일 안에 만료되면 그보다 오래된 레코드를 정리하거나 무시하십시오. 또한 각 사용자의 최신 레코드 만 유지하십시오. 목록의 크기는 토큰을 보관하는 기간과 사용자가 토큰을 철회하는 빈도에 따라 다릅니다. 테이블이 변경 될 때만 db를 사용하십시오. 응용 프로그램이 시작될 때 테이블을 메모리에로드하십시오.

---

사용자 당 고유 한 문자열과 함께 해시되는 전역 문자열

JWT 비밀 부분의 역할을 수행하여 개인 및 글로벌 토큰 무효화를 모두 허용합니다. 요청 인증 중 DB 조회 / 읽기 비용으로 최대의 유연성. 거의 변경되지 않기 때문에 캐시하기도 쉽습니다.

---

나는 다음과 같이했다 :

1. 를 생성 한 unique hash다음 redis 와 JWT 에 저장하십시오 . 이것을 세션 이라고 할 수 있습니다
   • 또한 특정 JWT 가 요청한 수를 저장합니다 . jwt가 서버로 전송 될 때마다 요청이 정수로 증가합니다 . (선택 사항)

따라서 사용자가 로그인하면 고유 한 해시가 생성되어 redis에 저장되고 JWT에 주입됩니다 .

사용자가 보호 된 엔드 포인트를 방문하려고하면 JWT 에서 고유 한 세션 해시를 가져와 redis를 쿼리하여 일치하는지 확인합니다.

이를 확장하고 JWT 를 더욱 안전하게 만들 수 있습니다. 방법은 다음과 같습니다.

특정 JWT 가 만든 모든 X 요청은 새로운 고유 세션을 생성하여 JWT에 저장 한 다음 이전 세션 을 블랙리스트에 추가합니다.

이것은 JWT 가 끊임없이 변화하고 있으며 오래된 JWT 가 해킹 당하거나 도난당하는 것을 막습니다.

---

사용자 토큰을 해지하려면 DB에서 발급 된 모든 토큰을 추적하고 세션과 같은 테이블에서 유효한 토큰이 있는지 확인할 수 있습니다. 단점은 모든 요청에 ​​대해 DB를 공격한다는 것입니다.

나는 그것을 시도하지 않았지만 DB 적중을 최소로 유지하면서 토큰 해지를 허용하는 다음 방법을 제안합니다-

데이터베이스 점검 비율을 낮추려면 일부 결정적 연관 (예 : 사용자 ID의 첫 번째 숫자로 10 개의 그룹)에 따라 발행 된 모든 JWT 토큰을 X 그룹으로 나누십시오.

각 JWT 토큰에는 그룹 ID와 토큰 작성시 작성된 시간 소인이 있습니다. 예를 들어{ "group_id": 1, "timestamp": 1551861473716 }

서버는 모든 그룹 ID를 메모리에 보유하고 각 그룹에는 해당 그룹에 속한 사용자의 마지막 로그 아웃 이벤트가 발생한 시간을 나타내는 타임 스탬프가 있습니다. 예를 들어{ "group1": 1551861473714, "group2": 1551861487293, ... }

더 오래된 그룹 타임 스탬프를 가진 JWT 토큰이있는 요청은 유효성 (DB 적중)을 검사하며, 유효한 경우 클라이언트가 나중에 사용할 수 있도록 새로운 타임 스탬프가있는 새로운 JWT 토큰이 발행됩니다. 토큰의 그룹 타임 스탬프가 최신이면 JWT (No DB hit)를 신뢰합니다.

그래서-

1. 토큰에 이전 그룹 타임 스탬프가있는 경우에만 DB를 사용하여 JWT 토큰의 유효성을 검사하지만 사용자 그룹의 누군가가 로그 아웃 할 때까지 향후 요청의 유효성이 검사되지 않습니다.
2. 그룹을 사용하여 타임 스탬프 변경 횟수를 제한합니다 (내일이없는 것처럼 로그인 및 로그 아웃하는 사용자가 있으므로 모두 대신 제한된 수의 사용자에게만 영향을 미침)
3. 메모리에 보유 된 타임 스탬프의 양을 제한하기 위해 그룹 수를 제한합니다
4. 토큰을 무효화하는 것은 쉬운 일입니다. 세션 테이블에서 토큰을 제거하고 사용자 그룹에 대한 새 타임 스탬프를 생성하십시오.

---

"모든 장치에서 로그 아웃"옵션을 사용할 수있는 경우 (대부분의 경우) :

• 토큰 버전 필드를 사용자 레코드에 추가하십시오.
• 이 필드의 값을 JWT에 저장된 클레임에 추가하십시오.
• 사용자가 로그 아웃 할 때마다 버전을 늘리십시오.
• 토큰의 유효성을 검사 할 때 버전 클레임을 사용자 레코드에 저장된 버전과 비교하고 동일하지 않은 경우 거부하십시오.

어쨌든 대부분의 경우 사용자 레코드를 가져 오는 db 트립이 필요하므로 유효성 검사 프로세스에 많은 오버 헤드가 발생하지 않습니다. 블랙리스트를 유지 관리하는 것과 달리 조인 또는 별도의 호출을 사용해야하거나 오래된 레코드를 정리해야하기 때문에 DB로드가 중요한 경우.

---

모든 토큰 확인시 DB 조회가 없으면 해결하기가 정말 어려워 보입니다. 내가 생각할 수있는 대안은 무효화 된 토큰의 블랙리스트를 서버 측에 유지하는 것입니다. 서버가 재시작시 데이터베이스를 검사하여 현재 블랙리스트를로드하도록하여 변경 사항이 발생할 때마다 데이터베이스에서 업데이트되어야합니다.

그러나 서버 메모리 (전역 변수)에 보관하면 둘 이상의 서버를 사용하는 경우 여러 서버에서 확장 할 수 없으므로 공유 Redis 캐시에 보관할 수 있습니다. 다시 시작해야 할 경우를 대비하여 데이터를 어딘가에 유지하도록 설정하고 (데이터베이스? 파일 시스템?) 새 서버가 회전 할 때마다 Redis 캐시를 구독해야합니다.

동일한 솔루션을 사용하는 블랙리스트의 대안으로, 다른 답변이 지적한 것처럼 세션 당 redis에 저장된 해시로 할 수 있습니다 (많은 사용자가 로그인하는 것이 더 효율적일지는 확실하지 않습니다).

너무 복잡하게 들립니까? 그것은 나에게한다!

면책 조항 : 나는 Redis를 사용하지 않았습니다.

---

------------------------이 답변에 늦었지만 누군가에게 도움이 될 수 있습니다 .-------------- -----------

클라이언트 측 에서 가장 쉬운 방법은 브라우저 스토리지에서 토큰을 제거하는 것입니다.

그러나 노드 서버에서 토큰을 제거하려면 어떻게해야합니까?

JWT 패키지의 문제점은 토큰을 파기하는 방법이나 방법을 제공하지 않는다는 것입니다. 위에서 언급 한 JWT와 관련하여 다른 방법을 사용할 수 있습니다. 그러나 여기에 나는 jwt-redis와 함께 간다.

따라서 서버 측에서 토큰을 제거하기 위해 JWT 대신 jwt-redis 패키지를 사용할 수 있습니다

이 라이브러리 (jwt-redis)는 jsonwebtoken 라이브러리의 모든 기능을 하나의 중요한 추가 기능과 함께 완전히 반복합니다. Jwt-redis를 사용하면 토큰 레이블을 redis에 저장하여 유효성을 확인할 수 있습니다. redis에 토큰 레이블이 없으면 토큰이 유효하지 않습니다. jwt-redis에서 토큰을 파괴하려면 destroy 메소드가 있습니다.

그것은 이런 식으로 작동합니다 :

1) npm에서 jwt-redis 설치

2) 만들기-

var redis = require('redis');
var JWTR =  require('jwt-redis').default;
var redisClient = redis.createClient();
var jwtr = new JWTR(redisClient);

jwtr.sign(payload, secret)
    .then((token)=>{
            // your code
    })
    .catch((error)=>{
            // error handling
    });

3) 확인 -

jwtr.verify(token, secret);

4) 파괴 -

jwtr.destroy(token)

참고 : JWT에서 제공되는 것과 동일한 방식으로 토큰 로그인 중에 expiresIn을 제공 할 수 있습니다.

누군가에게 도움이 될 수 있습니다.

---

사용자 테이블에 토큰을 저장하고 사용자 로그인시 새 토큰을 업데이트하고 인증이 사용자 현재 jwt와 같을 때.

이것이 최선의 해결책은 아니지만 저에게 효과적이라고 생각합니다.

참고 URL : https://stackoverflow.com/questions/21978658/invalidating-json-web-tokens