Devo armazenar minhas reivindicações de usuário no token JWT?

Estou usando tokens JWT em cabeçalhos HTTP para autenticar solicitações para um servidor de recursos. O servidor de recursos e o servidor de autenticação são duas funções de trabalho separadas no Azure.

Não consigo decidir se devo armazenar as reivindicações no token ou anexá-las à solicitação / resposta de alguma outra maneira. A lista Reivindicações afeta a renderização dos elementos da interface do usuário do lado do cliente, bem como o acesso aos dados no servidor. Por esse motivo, quero garantir que as solicitações recebidas pelo servidor sejam autênticas e validadas antes do processamento da solicitação.

Exemplos de declarações são: CanEditProductList, CanEditShopDescription, CanReadUserDetails.

Os motivos pelos quais desejo usar o token JWT para eles são:

Melhor proteção contra a edição de declarações do lado do cliente (por exemplo, lista de reivindicações de hackers).
Não há necessidade de procurar as reivindicações em cada solicitação.

Os motivos pelos quais não quero usar o token JWT:

O servidor de autenticação precisa conhecer a lista de reivindicações centradas no aplicativo.
O token se torna um ponto único de entrada de hackers.
Li algumas coisas dizendo que os tokens JWT não se destinam a dados no nível do aplicativo.

Parece-me que ambos têm desvantagens, mas estou inclinado a incluir essas declarações no token e só quero executá-lo por pessoas que já lidaram com isso antes.

OBSERVAÇÃO: usarei HTTPS para todas as solicitações de API; portanto, parece-me que o token estará seguro 'o suficiente'. Estou usando AngularJS, C #, API da Web 2 e MVC5.

— Astravagrant
fonte

lendo isso agora .... e gostaria de uma atualização, se puder. Eu estaria interessado no que você fez, pois estou enfrentando o mesmo ... pensando e sinto falta de como algumas das partes devem funcionar. O usuário recebe um token de autorização, mas como as reivindicações devem ser realizadas ... você poderia explicar suas descobertas ... pois isso provavelmente me ajudaria.

— Seabizkit

Respostas:

Eu armazeno apenas declarações de identificador (ID do usuário, etc.) (criptografadas) no meu jwt.

Então, quando eu recebo o token no servidor (API), posso fazer uma pesquisa no lado do servidor (db ou chamada de API da rede local) e recuperar todas as associações para o ID do usuário (aplicativos, funções etc.)

No entanto, se você quiser incluir mais detalhes no jwt, tenha cuidado com o tamanho, pois ele provavelmente será enviado em cada solicitação, mas certifique-se de criptografar dados confidenciais da declaração.

— wchoward
fonte

Saúde, DL. Você armazena em cache as funções etc. no servidor da API ou apenas atinge o banco de dados duas vezes toda vez que recebe uma solicitação? (ou seja, uma vez para as funções e uma vez para os dados reais sendo solicitados). Se você armazená-lo em cache, eu estaria interessado em saber qual método você usa. Além disso, você quer dizer que criptografa ainda mais o ID do usuário 'dentro' do token já criptografado? Obrigado.

— 21815 Astravagrant

Ainda não cheguei tão longe na minha implementação :), mas sim, eu estava pensando em usar um servidor de armazenamento em cache para não atingir o banco de dados com tanta frequência e se uma função mudar, o cache poderia ser removido para permitir que o novo função consultada para ser carregada em cache salvo. No meu caso, provavelmente usaria o Amazon AWS elsticache, que é baseado no memcached aberto, mas mais fácil de configurar e usar.

— Wchoward

Eu também acho que é uma idéia melhor obter todas as informações necessárias no servidor de recursos e não armazená-las em um token.

— Mateusz Migała

portanto, para cada solicitação que você obtém as funções dos usuários ... reivindicações ..., você poderia me indicar um artigo ou algo que mostre isso viável. atualmente estou usando a sessão, mas procurando uma maneira melhor de fazer as coisas, mas a pesquisa em cada solicitação não parece certa?

— Seabizkit

Parece que autenticação (quem é o usuário) e autorização (o que o usuário tem permissão para fazer) não são tão claramente divididas quanto você gostaria.

Se você não deseja que o servidor de autenticação saiba ao que o usuário tem direito, limite as reivindicações nesse JWT ao ID do usuário, como sugerido por wchoward. Você pode fazer outro servidor conhecido como servidor de autorização procurar o que o usuário tem direito.

A etapa de autorização pode ser realizada pelo servidor de recursos quando apresentado pela primeira vez um token de autenticação pelo cliente. O servidor de recursos enviaria um token para o cliente contendo reivindicações de autorização.

Nota: Os dois JWTs devem ser assinados por chaves diferentes.

Prós:

Autenticação e autorização são gerenciadas separadamente.
O servidor de recursos não precisa procurar autorização em cada solicitação.
A interface do usuário tem acesso para ver a autorização, mas não para editá-la.

Vigarista:

O cliente precisa manipular dois tokens em vez de um.
A adição de um servidor de autorização adiciona outra parte móvel a ser gerenciada.

— Chad Clark
fonte

Não se esqueça de que, mesmo ao verificar a autorização na interface do usuário, você ainda precisa verificar a autorização no servidor quando uma solicitação chegar.

— Chad Clark #