Autenticação RESTful. Autenticação do lado do cliente, sem estado

Estou implementando um conjunto de serviços RESTful para alguns desenvolvimentos e um deles é umserviço de autenticação.

esteserviço de autenticação autentica dois tipos de identidades:

Aplicações. Autenticação baseada em AppKey para que os clientes se registrem em uma chave para acessar o restante dos serviços.Comercial. Autenticação de usuário baseada em credenciais bem conhecidas (usuário + senha) para que humanos e máquinas possam trabalhar com esses serviços RESTful por meio de aplicativos clientes.

Esses serviços RESTfulestásem estado.

Quando um aplicativo cliente se autentica contra oserviço de autenticação, ou quando um humano ou uma máquina autentica como uma identidade usando credenciais, ambas as operações geramAppToken eUserToken respectivamente.

Esses tokens são um hash salgado para que as solicitações subsequentes à infraestrutura RESTful sejam autenticadas sem compartilharAppKeys ecredenciais.

Formar o ponto de vista de uma abordagem totalmente sem estado, esses tokens devem ser armazenados em nenhum lugar na camada de serviço, mas em algum tipo de estado do lado do cliente (por exemplo, um cliente da Web o armazenaria usandoCookies HTTP).É assim que minhas implementações atuais estão funcionando agora.

Porque a re-autenticação de cada solicitação usando estestokens e deixe a camada de serviço receber o token vindo do cliente para que ele possa compararque token vem do cliente everifique se é um token válido, re-gerando-o na camada de serviço e compare com o que pertence ao cliente é muito caro, eu implementei uma camada de serviçoAppToken eUserToken, ambos tendo uma data de expiração e um proprietário (o aplicativo ou usuário para o qual o token foi criado), para verificar se o token proveniente do cliente existe no token store.

Como os clientes interativamente não autenticam? Apenas soltando o estado de segurança do lado do cliente. Se for um cliente da Web, ele descartará o cookie de autenticação e apenas atualizará a página, o cliente não detectará nenhum cookie de autenticação e o usuário será redirecionado para a página de login.

Do ponto de vista dos serviços RESTful,isso é uma falta de autenticação stateless: os clientes não estão cientes sobre otruque de ter um estado de pseudo-autenticação da camada de serviço.É apenas um detalhe de implementação de serviço - uma otimização de desempenho -.

Eu não vou listar opros de serviços sem estado, porque tenho absoluta certeza de que essa abordagem é o caminho a percorrer, mas acho um problema:Autenticação / autenticação sem estados significa que os clientes não notificam o servidor de que eles fecharam sua sessão, portanto, o armazenamento de segurança termina com muitos registros inúteis.

Este não é um grande problema se os clientes do serviço são aqueles que teriam sessões de tempo limitado (por exemplo, 1 hora, 3 horas, um dia ...), maso que acontece se um usuário precisar ser autenticadopara sempre (8 meses, um ano)?. Como você distingueO que é um token expirado?

Existem algumas abordagens para resolver esta situação:

Sempre que a camada de serviço recebe uma solicitação, ela atualiza a data de expiração do token, portanto, um processo automatizado pode eliminar os tokens que expiraram, definindo uma expiração arbitrária de tokens (por exemplo, 24 horas)..

Comprometer a natureza sem estado da arquitetura e permitir que os clientes notifiquem a camada de serviço de que não querem mais ser autenticados, para que o serviço possa eliminar o token associado à sessão do cliente (Mas espere ... o que acontece se o cliente fechar um cliente da Web? O usuário nunca notificará ativamente o serviço de que o token deve ser descartado ... Então ... Os tokens de zumbis ainda estão lá, portanto, um processo automatizado deve descartá-los, mas ... o que é um token de zumbi?Eu não gosto dessa abordagem).

Autenticação completamente sem estado, sem armazenamento, autenticação por solicitação.

Esta é a questão! Qual é a sua abordagem sugerida - mesmo que não seja 1., 2. ou 3. - e por quê?

Obrigado por esta longa leitura - eu sinceramente acredito que as conclusões da pergunta serão extremamente úteis para qualquer um -!

questionAnswers(2)

yourAnswerToTheQuestion