Fluxo do token de atualização JWT

Estou criando um aplicativo móvel e estou usando o JWT para autenticação.

Parece que a melhor maneira de fazer isso é emparelhar o token de acesso JWT com um token de atualização, para que eu possa expirar o token de acesso com a frequência que desejar.

1. Como é um token de atualização? É uma string aleatória? Essa cadeia é criptografada? É outro JWT?
2. O token de atualização seria armazenado no banco de dados no modelo de usuário para acesso, correto? Parece que deve ser criptografado neste caso
3. Eu enviava o token de atualização de volta após o login do usuário e depois o cliente acessava uma rota separada para recuperar um token de acesso?

Supondo que se trata do OAuth 2.0, pois trata-se de JWTs e tokens de atualização ...:

1. Assim como um token de acesso, em princípio um token de atualização pode ser qualquer coisa, incluindo todas as opções que você descreve; uma JWT pode ser usada quando o Servidor de Autorização deseja não ter estado ou deseja impor algum tipo de semântica de "prova de posse" ao cliente que a apresenta; observe que um token de atualização difere de um token de acesso, pois ele não é apresentado a um servidor de recursos, mas apenas ao servidor de autorização que o emitiu em primeiro lugar; portanto, a otimização de validação independente para JWTs como tokens de acesso não segure para tokens de atualização

2. isso depende da segurança / acesso do banco de dados; se o banco de dados puder ser acessado por outras partes / servidores / aplicativos / usuários, então sim (mas sua milhagem pode variar de acordo com onde e como você armazena a chave de criptografia ...)

3. um Servidor de Autorização pode emitir tokens de acesso e tokens de atualização ao mesmo tempo, dependendo da concessão usada pelo cliente para obtê-los; a especificação contém os detalhes e as opções de cada um dos subsídios padronizados

Abaixo estão as etapas para revogar seu token de acesso JWT:

1. Ao fazer login, envie 2 tokens (token de acesso, token de atualização) em resposta ao cliente.
2. O token de acesso terá menos tempo de validade e a atualização terá um longo prazo de validade.
3. O cliente (Front end) armazenará o token de atualização em seu armazenamento local e o token de acesso nos cookies.
4. O cliente usará um token de acesso para chamar APIs. Porém, quando expirar, escolha o token de atualização no armazenamento local e chame a API do servidor de autenticação para obter o novo token.
5. Seu servidor de autenticação terá uma API exposta que aceitará o token de atualização e verificará sua validade e retornará um novo token de acesso.
6. Depois que o token de atualização expirar, o Usuário será desconectado.

Informe-me se precisar de mais detalhes. Também posso compartilhar o código (inicialização Java + Spring).

Para suas perguntas:

Q1: é outro JWT com menos solicitações feitas com longo prazo de validade.

P2: Não estará em um banco de dados. O back-end não será armazenado em nenhum lugar. Eles apenas descriptografam o token com chave privada / pública e o validam com seu tempo de expiração também.

Q3: Sim, correto

Com base nesta implementação com o Node.js do JWT com token de atualização :

1) Nesse caso, eles usam um uid e não é um JWT. Quando eles atualizam o token, eles enviam o token de atualização e o usuário. Se você implementá-lo como um JWT, não precisará enviar o usuário, porque ele seria dentro do JWT.

2) Eles implementam isso em um documento separado (tabela). Faz sentido para mim porque um usuário pode fazer login em diferentes aplicativos clientes e pode ter um token de atualização por aplicativo. Se o usuário perder um dispositivo com um aplicativo instalado, o token de atualização desse dispositivo poderá ser invalidado sem afetar os outros dispositivos conectados.

3) Nesta implementação, ele responde ao método de logon com o token de acesso e o token de atualização. Parece correto para mim.