session - password - rest cookie authentication




As sessões realmente violam o RESTfulness? (4)

  1. Sessões não são RESTless
  2. Você quer dizer que o serviço REST para uso somente http ou eu tenho errado? A sessão baseada em cookies deve ser usada apenas para serviços próprios (!) Baseados em http! (Pode ser um problema trabalhar com cookies, por exemplo, em Mobile / Console / Desktop / etc.)
  3. Se você fornecer serviço RESTful para desenvolvedores de terceiros, nunca use sessões baseadas em cookies, use os tokens para evitar problemas com segurança.

O uso de sessões em uma API RESTful está realmente violando o RESTfulness? Eu tenho visto muitas opiniões indo em qualquer direção, mas não estou convencido de que as sessões sejam RESTless . Do meu ponto de vista:

  • autenticação não é proibida para RESTfulness (caso contrário, haveria pouco uso em serviços RESTful)
  • autenticação é feita enviando um token de autenticação na solicitação, geralmente o cabeçalho
  • esse token de autenticação precisa ser obtido de alguma forma e pode ser revogado. Nesse caso, ele precisa ser renovado
  • o token de autenticação precisa ser validado pelo servidor (caso contrário, não seria autenticação)

Então, como as sessões violam isso?

  • no lado do cliente, as sessões são realizadas usando cookies
  • cookies são simplesmente um cabeçalho HTTP extra
  • um cookie de sessão pode ser obtido e revogado a qualquer momento
  • cookies de sessão podem ter um tempo de vida infinito, se necessário
  • o ID da sessão (token de autenticação) é validado no lado do servidor

Como tal, para o cliente, um cookie de sessão é exatamente o mesmo que qualquer outro mecanismo de autenticação baseado em cabeçalho HTTP, exceto que ele usa o cabeçalho Cookie vez da Authorization ou algum outro cabeçalho proprietário. Se não houvesse sessão anexada ao lado do servidor de valor de cookie, por que isso faria diferença? A implementação do lado do servidor não precisa se preocupar com o cliente, desde que o servidor se comporte como RESTful. Como tal, os cookies por si só não devem tornar uma API RESTless , e as sessões são simplesmente cookies para o cliente.

As minhas suposições estão erradas? O que torna os cookies de sessão RESTless ?


A transação HTTP, autenticação de acesso básico, não é adequada para o RBAC, porque a autenticação de acesso básico usa o nome de usuário criptografado: senha toda vez para identificar, enquanto que o RBAC é o papel que o usuário deseja usar para uma chamada específica. O RBAC não valida permissões no nome de usuário, mas em funções.

Você poderia trocar por concatenar assim: usernameRole: password, mas isso é uma prática ruim, e também é ineficiente porque quando um usuário tem mais funções, o mecanismo de autenticação precisaria testar todas as funções na concatenação e todas as chamadas novamente. Isso destruiria uma das maiores vantagens técnicas do RBAC, ou seja, um teste de autorização muito rápido.

Então, esse problema não pode ser resolvido usando a autenticação básica de acesso.

Para resolver este problema, a manutenção da sessão é necessária, e isso parece, de acordo com algumas respostas, em contradição com o REST.

Isso é o que eu gosto sobre a resposta que REST não deve ser tratado como uma religião. Em casos de negócios complexos, na área da saúde, por exemplo, o RBAC é absolutamente comum e necessário. E seria uma pena se eles não pudessem usar o REST porque todos os designers de ferramentas de REST tratariam o REST como uma religião.

Para mim, não há muitas maneiras de manter uma sessão por HTTP. Pode-se usar cookies, com um sessionId, ou um cabeçalho com um sessionId.

Se alguém tiver outra ideia, ficarei feliz em ouvi-la.


Os cookies não são para autenticação. Por que reinventar uma roda? O HTTP possui mecanismos de autenticação bem projetados. Se usarmos cookies, cairemos no uso de HTTP como um protocolo de transporte, portanto, precisamos criar nosso próprio sistema de sinalização, por exemplo, para informar aos usuários que eles forneceram autenticação errada (usar HTTP 401 seria incorreto, pois provavelmente não fornecer Www-Authenticate para um cliente, como especificações de HTTP requerem :)). Também deve ser notado que o Set-Cookie é apenas uma recomendação para o cliente. Seu conteúdo pode ou não ser salvo (por exemplo, se os cookies estiverem desabilitados), enquanto o cabeçalho de Authorization é enviado automaticamente em todas as solicitações.

Outro ponto é que, para obter um cookie de autorização, você provavelmente vai querer fornecer suas credenciais em algum lugar primeiro? Se sim, então não seria RESTless? Exemplo simples:

  • Você tenta GET /a sem cookie
  • Você recebe um pedido de autorização de alguma forma
  • Você vai e autoriza de alguma forma como POST /auth
  • Você ganha Set-Cookie
  • Você tenta GET /a com cookie. Mas o GET /a se comporta de forma idêmica neste caso?

Resumindo, acredito que, se acessarmos algum recurso e precisarmos autenticar, devemos nos autenticar nesse mesmo recurso , e não em qualquer outro lugar.


Primeiro de tudo, o REST não é uma religião e não deve ser abordado como tal. Embora haja vantagens para os serviços RESTful, você deve seguir apenas os princípios do REST, desde que eles façam sentido para o seu aplicativo.

Dito isso, a autenticação e o estado do lado do cliente não violam os princípios do REST. Enquanto o REST requer que as transições de estado sejam sem estado, isso está se referindo ao próprio servidor. No coração, todo o REST é sobre documentos. A ideia por trás da apatridia é que o servidor é stateless, não os clientes. Qualquer cliente que emita uma solicitação idêntica (mesmos cabeçalhos, cookies, URI, etc.) deve ser levado ao mesmo local no aplicativo. Se o site armazenou a localização atual do usuário e a navegação gerenciada atualizando essa variável de navegação do lado do servidor, o REST seria violado. Outro cliente com informações de solicitação idênticas seria levado a um local diferente, dependendo do estado do lado do servidor.

Os serviços da web do Google são um exemplo fantástico de um sistema RESTful. Eles exigem um cabeçalho de autenticação com a chave de autenticação do usuário para ser passada em cada solicitação. Isso viola os princípios do REST, porque o servidor está rastreando o estado da chave de autenticação. O estado dessa chave deve ser mantido e tem algum tipo de data / hora de expiração após a qual não concede mais acesso. No entanto, como mencionei no início do meu post, sacrifícios devem ser feitos para permitir que um aplicativo realmente funcione. Dito isto, os tokens de autenticação devem ser armazenados de forma a permitir que todos os clientes possíveis continuem a conceder acesso durante os seus tempos válidos. Se um servidor estiver gerenciando o estado da chave de autenticação até o ponto em que outro servidor de carga balanceada não possa assumir solicitações de preenchimento com base nessa chave, você começou a violar realmente os princípios do REST. Os serviços do Google garantem que, a qualquer momento, você possa usar um token de autenticação em seu telefone contra o servidor de balanceamento de carga A e acessar o servidor de balanceamento de carga B de sua área de trabalho e ainda ter acesso ao sistema e ser direcionado para os mesmos recursos os pedidos eram idênticos.

O que tudo isso se resume é que você precisa garantir que os seus tokens de autenticação sejam validados contra um armazenamento de apoio de algum tipo (banco de dados, cache, seja o que for) para garantir a preservação do máximo possível de propriedades REST.

Espero que tudo isso tenha sentido. Você também deve verificar a seção Restrições do wikipedia da wikipedia caso ainda não o tenha feito. É particularmente esclarecedor em relação ao que os princípios do REST estão realmente argumentando e por quê.







restful-authentication