Em um artigo anterior, falei sobre o básico do JWT . Se estiver nos seus dedos, essa é apenas a chave com a qual abrimos a porta para recursos privados. Mas e se essa chave for roubada (mais precisamente, eles criarão uma duplicata). Depois, alguém poderá fazer login no servidor com o seu nome, e talvez nem saibamos disso. Não queremos permitir esse cenário. Mas o que fazer?
Aumentar a segurança
Sugiro aos leitores, antes de seguirem de forma independente, que pensem no que podemos fazer com segurança.
Aqui estão algumas abordagens que podem melhorar a segurança. Você pode escrever nos comentários quais outras abordagens existem - eu as adicionarei.
- Usando o protocolo
https , que protege o canal de dados pela Internet. De fato, este é um invólucro sobre http , que impõe protocolos criptográficos adicionais - SSL e TLS - Adicionando informações de
IP à payload . Em seguida, o token de outros IP não passará na verificação. Mas o IP pode ser falsificado e o que fazer com endereços IP dinâmicos ou quando um usuário se conecta a partir de um telefone em um café ou metrô. Portanto, não usaremos essa abordagem. - Use
RS256 . Isso garante a segurança da própria chave privada. Mas com tokens, tudo permanece absolutamente como estava. Precisamos do RS256 quando temos medo de passar a chave secreta para outros servidores, o que pode não ser confiável. Damos a eles apenas uma ferramenta de autenticação de token, que é absolutamente inútil para um invasor. - Use tokens de vida curta. Mas o usuário terá que fazer login novamente toda vez que expirar. Cedo ou tarde, o usuário ficará entediado e deixará nosso recurso.
- Mas e se você usar tokens de vida curta de qualquer maneira, mas fornecer outro token, cujo objetivo é apenas obter um novo token de vida curta sem uma nova autorização? Esse token é chamado de token de atualização e será possível usá-lo apenas uma vez. Este será o meu artigo.
Lembre-se do que é o JWT
JWT tira proveito das JWE codificação JWS (Assinatura) e JWE (Criptografia). A assinatura não permite que alguém falsifique um token sem informações sobre a chave secreta e a codificação protege contra a leitura de dados por terceiros.
Vamos ver como eles podem nos ajudar a autenticar e autorizar o usuário no site.
Autenticação (autenticação em inglês; do grego. Αὐθεντικός [authentikos] - real, autêntico; de αὐθέντης [authentes] - o autor) - procedimento de autenticação. No nosso caso, verificamos o login + senha para uma correspondência com a entrada no banco de dados de dados do usuário.
Autorização (autorização em inglês - permissão, autorização) - fornecendo ao usuário o direito de executar determinadas ações; e também o processo de verificação (confirmação) desses direitos ao tentar executar essas ações.
Em outras palavras, a autenticação verifica a legalidade do usuário e, se tudo estiver bem, o usuário se torna autorizado, ou seja, ele pode executar ações permitidas com o banco de dados. Geralmente, esses dois processos são combinados e, portanto, há uma confusão bem conhecida.
Tipos de tokens
- Tokens de acesso (JWTs) são tokens que podem ser usados para acessar recursos protegidos. Eles têm vida curta , mas são reutilizáveis . Eles podem conter informações adicionais, como tempo de vida ou endereço
IP de onde a solicitação vem. Tudo depende do desejo do desenvolvedor. - Atualizar Token (RT) - esses tokens executam apenas uma tarefa específica - obter um novo token de acesso. E desta vez você não pode ficar sem um servidor de autorização. Eles têm vida longa , mas são descartáveis .
O principal caso de uso é este: assim que o JWT antigo expirar, não podemos mais receber dados privados com ele, enviamos RT e recebemos um novo par de JWT+RT . Com o novo JWT podemos novamente recorrer a recursos privados. Obviamente, um token de atualização também pode dar errado, mas isso não acontecerá em breve, porque ele vive muito mais que o irmão.
A idéia principal da separação de tokens é que, por um lado , os tokens de autorização nos permitem verificar facilmente um usuário sem um servidor de autorização, simplesmente comparando assinaturas.
const validateToken = token => { const [ header, payload, signature ] = token.split('.'); return signature === HS256(`${header}.${payload}`, SECRET_KEY); }
Por outro lado , temos uma
Em conclusão
Graças a essa abordagem, reduzimos o tempo de espera para acessar o servidor de latency e a própria lógica do servidor se torna muito mais simples. E, do ponto de vista da segurança, se um token de acesso foi roubado de nós, apenas um tempo limitado poderá usá-lo - não mais que sua vida útil. Para que um invasor possa usar por mais tempo, ele também precisará roubar uma atualização, mas o usuário real saberá que ele foi hackeado porque será expulso do sistema. E assim que esse usuário fizer login novamente, ele receberá um par atualizado de JWT+RT , e os roubados se transformarão em abóbora.
Links úteis
- Por que preciso atualizar o token se tenho o token de acesso?
- Atualizar tokens: quando usá-los e como eles interagem com os JWTs
- Mais surpresas do OAuth 2.0: o token de atualização