Oi já escreveu esta observação e pergunta sobreessa questão anteriormente, mas só mais tarde percebeu que era uma questão antiga e "morta". Como eu realmente gostaria de algumas idéias dos outros, estou repostando isso como uma nova pergunta.

Para a questão de como fazer a autenticação RESTfully, as pessoas geralmente enthousiastically gritar "Autenticação HTTP". No entanto, eu tenho dúvidas se essas pessoas já tentaram fazer um navegador baseadoaplicação (em vez de um serviço da web máquina-a-máquina) com REST. (sem ofensa pretendida - só acho que nunca enfrentaram as complicações)

Os problemas que encontrei com o uso da Autenticação HTTP em serviços RESTful que produzem páginas HTML para exibição em um navegador são:

o usuário geralmente obtém uma caixa de login feia feita pelo navegador, que não é amigável ao usuário. você não pode adicionar recuperação de senha, caixas de ajuda, etcetera.fazer logout ou fazer login com um nome diferente é um problema - os navegadores continuarão enviando informações de autenticação para o site até que você feche a janelaTempos limite são difíceis

Um artigo muito perspicaz que aborda esses pontos por ponto éAqui, mas isso resulta em ummuito de hackery javascript específico do navegador, soluções alternativas para soluções alternativas, etc. Como tal, também não é compatível com versões futuras, o que requer manutenção constante à medida que novos navegadores são liberados. Eu não considero esse design limpo e claro, mais eu sinto que é muito trabalho extra e dor de cabeça só para que eu possa mostrar meu REST-crachá aos meus amigos.

Eu acredito que os cookies são a solução. Mas espere, biscoitos são maus, não são? Não, eles não são, a maneira como os cookies são usados ​​com frequência é má. Um cookie em si é apenas uma informação do lado do cliente, assim como as informações de autenticação HTTP que o navegador acompanharia enquanto você navega. E essa parte das informações do lado do cliente é enviada ao servidor em todas as solicitações, mais uma vez exatamente como as informações da Autenticação HTTP. Conceitualmente, a única diferença é que oconteúdo desta parte do estado do lado do cliente pode ser determinado peloservidor como parte de sua resposta.

Tornando as sessões um recurso RESTful apenas com as seguintes regras:

A sessão mapeia uma chave para um ID de usuário (e possivelmente um carimbo de data e hora da última ação para tempos limite)Se umsessão existe, então isso significa que a chave é válida.Login significa POSTING para / sessions, uma nova chave é definida como um cookieLogout significa DELETEing / sessions / {key} (com o POST sobrecarregado, lembre-se, nós somos um navegador e o HTML 5 ainda é um longo caminho a percorrer)A autenticação é feita enviando a chave como um cookie em cada solicitação e verificando se a sessão existe e é válida

A única diferença para a Autenticação HTTP, agora, é que a chave de autenticação é gerada pelo servidor e enviada ao cliente que continua enviando de volta, em vez de o cliente computá-la a partir das credenciais inseridas.

Eu sinto que esta é uma solução suficiente que funciona bem, mas devo admitir que não sou especialista em segurança suficiente para identificar possíveis falhas neste esquema - tudo o que sei é que centenas de aplicações web não-REST usam essencialmente o mesmo protocolo de login ($ _SESSION inphp, HttpSession no j2ee, etc). O conteúdo do cabeçalho do cookie é simplesmente usado para endereçar um recurso do lado do servidor, assim como uma linguagem aceita pode ser usada para acessar recursos de tradução, etc. Eu sinto que é o mesmo, mas talvez outros não o façam? O que vocês acham pessoal?