As permissões e funções de acesso devem ser incluídas na carga útil do JWT?

As informações sobre as permissões e funções do cliente devem ser incluídas no JWT?

Ter essas informações no token JWT será muito útil, pois sempre que um token válido chega, seria mais fácil extrair as informações sobre a permissão do usuário e não será necessário chamar o banco de dados para o mesmo. Mas incluir essas informações e não verificar as mesmas no banco de dados será um problema de segurança?

Ou,

Informações como a mencionada acima nunca devem fazer parte da JWT, e apenas o banco de dados deve ser usado para verificar as funções de acesso e as permissões de um usuário?

security authentication jwt

— Anshul Sahni
fonte

Respostas:

O objetivo de incluir reivindicações no token é para que você não precise ter essa comunicação entre o recurso e o provedor de autenticação.

O recurso pode apenas verificar se o token possui uma assinatura válida e confiar no conteúdo.

Supondo que a chave privada seja privada para o servidor de autenticação, você é bom. Alguns fornecedores mudam de chave para reduzir o risco.

Se você pensar bem, se o recurso fez uma chamada de volta ao servidor de autenticação para obter as reivindicações. Então, é essencial garantir que ele esteja conversando com o servidor certo por métodos de confiança semelhantes.

— Ewan
fonte

Bem, obrigado por uma bela resposta, posso saber mais sobre o que você quis dizer com sua declaração "Alguns provedores mudam de chave para reduzir o risco". ?

— Anshul Sahni

Portanto, em vez de ter uma chave de assinatura fixa, o provedor de autenticação a altera de vez em quando e fornece um ponto de extremidade para os servidores de recursos fazerem o download da metade pública. Os recursos têm de fazer chamadas para o servidor de autenticação de vez em quando, mas não uma vez por solicitação

— Ewan

Assim, todos os sinais são cada vez inválida a assinatura chave é alterada pelo serviço

— Anshul Sahni

normalmente eles terão mais de uma chave possível, para que os tokens em voo não sejam invalidados. o token irá conter um 'id chave' para dizer o recurso qual usar

— Ewan

A única coisa que sinto falta aqui é como proceder quando os dados no JWT são invalidados. Digamos que as funções foram alteradas no lado do servidor, mas o cliente ainda mantém o token com todo o conjunto de funções. Você deve poder revogar tokens no lado do servidor para que os tokens com informações desatualizadas não sejam mais válidos e utilizáveis para solicitações adicionais. Isso está de acordo com o que Ewans está de alguma forma sugerindo (permitindo que o servidor revogue o token) por um ou outro motivo.

— 19419 Laiv

Pela minha experiência, se todos os seus sistemas estiverem usando algum banco de dados central de permissões e funções, você poderá adicionar tudo isso ao JWT.

No entanto, essa abordagem pode não funcionar bem em cenários de SSO quando o próprio servidor de autenticação não tem idéia alguma sobre o sistema de destino que receberá e confiará no token.

As funções e permissões do usuário são inteiramente do destinatário do token JWT. É especialmente verdade quando você integra a autenticação SSO ao JWT em alguns sistemas legados que já possuem seu subsistema de permissão e, portanto, eles precisam de apenas uma declaração para estar presente na JWT - a reivindicação da identidade do usuário.

— JustAMartin
fonte

Eu concordo com isso. As permissões de usuário não devem fazer parte do jwt, especialmente no SSO, pois o idp não está ciente de quais outros serviços esse usuário jwt irá conversar. Em vez disso, o recurso deve implementar a parte de autorização assim que a identidade for confirmada para o usuário

— Manish Rawat

Também concordo que as solicitações de permissão nos JWTs não são uma boa idéia além de uma simples API monolítica. Eu escrevi um post sobre o assunto: sdoxsee.github.io/blog/2020/01/06/…

— sdoxsee