Os cookies devem ser usados ​​em uma API RESTful?

77

Estou especificamente interessado em como os usuários executam operações autorizadas / autenticadas em uma API da web.

Os cookies de autenticação são compatíveis com a filosofia REST e por quê?

Brandon Linton
fonte
duplicata exata de restful-authentication
1
@JarrodRoberson Meu entendimento era que as respostas em outro site não se qualificariam a questão de duplicar aqui
Tom Squires
5
@JarrodRoberson com base nas perguntas frequentes de cada site, eu diria que a pergunta pertence a este site e não ao Stack Overflow. Estou interessado em metodologia / filosofia de design e vantagens e desvantagens em relação a esse aspecto da arquitetura RESTful. O Stack Overflow destina-se a perguntas de implementação, em que este site é mais sobre metodologias de design e trocas.
Brandon Linton
1
Eu concordo com o @BrandonLinton aqui, a questão é muito ampla para o Stackoverflow, é uma questão de arquitetura e metodologia de design. O OP deseja boas práticas e padrões, sugestões e dicas - não uma resposta específica -, portanto, nenhum idioma foi especificado. Por isso, pertence aqui.
Dooburt

Respostas:

81

Um serviço ReSTful ideal permite que os clientes (que podem não estar no navegador) executem qualquer tarefa necessária em uma solicitação ; porque o estado completo necessário para isso é mantido pelo cliente, não pelo servidor. Como o cliente tem controle total do estado, ele pode criar o estado por conta própria (se for legítimo), e apenas conversar com a API para "concluir".

Exigir cookies pode tornar isso difícil. Para clientes além dos navegadores, gerenciar cookies é um inconveniente bastante grande comparado aos parâmetros de consulta, cabeçalhos simples de solicitação ou corpo da solicitação. Por outro lado, no navegador, o uso de cookies pode tornar muitas coisas muito mais simples.

Portanto, uma API pode procurar primeiro no Authorizationcabeçalho os dados de autenticação de que precisa, já que provavelmente é o lugar onde os clientes que não são navegadores preferem colocá-los, mas para simplificar e otimizar os clientes baseados em navegador, também pode procurar um cookie de sessão para logon no servidor, mas apenas se o Authorizationcabeçalho regular estiver ausente.

Outro exemplo pode ser uma solicitação complexa que normalmente requer muitos parâmetros configurados. Um cliente não interativo não teria problemas para agrupar todos esses dados em uma solicitação, mas uma interface baseada em formulário HTML pode preferir dividir a solicitação em várias páginas (algo como um conjunto de páginas de 'assistente') para que os usuários não sejam apresentados com opções que não são aplicáveis ​​com base nas seleções anteriores. Todas as páginas intermediárias podem armazenar os valores nos cookies do lado do cliente, para que apenas a última página, na qual o usuário realmente envia a solicitação, tenha algum efeito colateral no servidor. A API poderia procurar os atributos necessários no corpo da solicitação e voltar a examinar os cookies se os parâmetros necessários não estivessem lá.

Edit: no RE para o comentário do @ Konrad abaixo:

Os tokens em comparação são mais difíceis de implementar, especialmente porque você não pode invalidar facilmente o token sem armazená-los em algum lugar.

er ... você está validando os cookies no servidor, certo? Só porque você disse ao navegador para descartar um cookie após 24 horas não significa que sim. Esse cookie pode ser salvo por um usuário altamente técnico e reutilizado muito tempo depois de "expirar".

Se você não deseja armazenar dados da sessão no lado do servidor, deve armazená-los no token (cookie ou não). Às vezes, um token de autenticação independente é chamado de Macaroon. Como isso é passado entre cliente e servidor (seja por cookie, como cabeçalhos extras ou na própria entidade de solicitação) é totalmente independente do mecanismo de autenticação.

SingleNegationElimination
fonte
4
+1, eu definitivamente gosto da praticidade de usar o cabeçalho de autorização, mas "voltar a" aos cookies, dependendo do que funciona melhor para o cliente.
Brandon Linton
Não concordo com "Para clientes além de navegadores, gerenciar cookies é um grande inconveniente ...". A maioria das bibliotecas de clientes HTTP suporta cookies, por exemplo, HttpClientno .NET você pode usar cookies sem nenhum problema e não precisa pensar muito sobre isso. Os tokens em comparação são mais difíceis de implementar, especialmente porque você não pode invalidar facilmente o token sem armazená-los em algum lugar.
314 Konrad Konrad
1
O @Konrad apenas porque é fácil em alguns clientes que não são navegadores, não significa que é fácil em todos eles. Tudo bem se você precisar apenas oferecer suporte ao cliente específico que você usa, mas eu interpretei a pergunta sobre APIs voltadas para o público. em curlou wget, gerenciar cookies é muito danado inconveniente e você realmente tem que pensar sobre eles um monte. Eu respondi ao seu outro ponto editando minha resposta.
SingleNegationElimination
Lembre-se de que simplesmente aceitar cookies abre vulnerabilidades de CSRF. Veja também security.stackexchange.com/a/166798
Michael Osl
14

Sim e não - depende de como você o usa.

Os cookies, se utilizados para manter o estado do cliente no cliente, para o cliente, do cliente e pelo cliente, são repousantes.

Se você está armazenando o estado do servidor no cookie, basicamente está apenas transferindo a carga para o cliente - o que não é tranquilo.

Então, quais são alguns exemplos?

Repousante:

  • Detalhes de autenticação ou 'está logado'
  • última página visualizada ou local no aplicativo etc.

Não repousante:

  • Armazenando informações da sessão

A tranquilidade vem da apatridia - do servidor. Os clientes podem manter o estado do aplicativo e enviá-lo ao servidor para dizer onde estão, para que o servidor possa decidir para onde ir a partir daí. Basicamente, as sessões / estados precisam de dados históricos e dependem de solicitações anteriores, por exemplo, aplicativos repousantes não são ideais (não é viável ter um aplicativo repousante 100% puro, se você tiver uma tela de login :)

Doutorado
fonte
10
Se você armazenar um sinalizador "isLoggedIn" no cliente, poderá também não usar nenhuma autenticação.
23612 tdammers #
Definitivamente, faz sentido - o armazenamento do estado do aplicativo no lado do cliente não seria consistente com o REST, mas as informações do cliente que ele usa para se representar parecem boas.
Brandon Linton
1
Gostaria de acrescentar que a colocação de informações de autenticação em cookies deixa em aberto a possibilidade de ataques de falsificação de solicitação entre sites. Existem maneiras melhores, sugiro copiar a Amazon: docs.aws.amazon.com/AmazonS3/latest/API/…
Dobes Vandermeer
@ tdammers e se a bandeira "isLoggedIn" estiver em um JWT? Isso deve ser seguro, desde que o JWT seja emitido e verificado corretamente.
Aaron J Spetner
@AaronJSpetner: Não use o JWT para sessões .
tdammers 01/09/17
12

Pode-se usar cookies. O REST permite.

O REST exige que todas as informações da sessão sejam armazenadas no lado do cliente, mas quando se trata de autenticação, algumas informações precisam permanecer no lado do servidor por motivos de segurança.

Em uma das postagens do meu blog , existe um acordo geral de que os dados de autenticação são considerados fora do escopo em relação ao REST. Portanto, não há problema em os servidores manterem alguns dados desta sessão do lado deles.

Jérôme Verstrynge
fonte