Autorizando solicitações REST

Question

Estou trabalhando em um serviço REST que possui alguns requisitos:

1. Tem que ser seguro.
2. Os usuários não devem poder falsificar solicitações.

Minha solução proposta atual é ter um cabeçalho de autorização personalizado parecido com este (é a mesma maneira que os serviços da web da Amazon funcionam):

Authorization: MYAPI username:signature

Minha dúvida é como formar a assinatura.Quando o usuário faz login no serviço, ele recebe uma chave secreta que deve poder usar para assinar solicitações.Isso impedirá que outros usuários enviem solicitações em seu nome, mas não os impedirá de falsificar solicitações.

O aplicativo que usará este serviço é um aplicativo para iPhone, então pensei que poderíamos ter uma chave pública incorporada no aplicativo com a qual poderíamos fazer uma assinatura adicional, mas isso significa que teremos que ter duas assinaturas, uma para a chave do usuário e outra para a chave do aplicativo?

Qualquer conselho seria muito apreciado, eu gostaria muito de acertar na primeira vez.

Answer 1

Eu acho que a maneira mais simples de fazer isso direito seria usar a autenticação do cliente HTTPS. O site da Apple tem um fio sobre este assunto.

EDIT: Para lidar com a autorização, eu criaria um recurso separado (URI) no servidor para cada usuário e só permitia que o usuário (autenticado) manipule esse recurso.

EDIT (2014): A Apple mudou seu software de fórum nos últimos seis anos; O tópico está agora em https://discussions.apple.com/thread/1643618

Answer 2

A resposta é simples:Isso não pode ser feito.Assim que você envia qualquer solução ao usuário final, ele sempre poderá atacar o servidor com o qual está se comunicando.A versão mais comum desse problema é trapacear com listas de pontuações altas em jogos Flash.Você consegue mais difícil incorporando algum tipo de criptografia no cliente e ofuscando o código...Mas todo código compilado e ofuscado sempre pode ser descompilado e não ofuscado.É apenas uma questão de quanto tempo e dinheiro você está disposto a gastar e também com o potencial invasor.

Então sua preocupação é não como tentar evitar que o usuário envie dados defeituosos para o seu sistema.É como evitar que o usuário prejudicial Seu sistema.Você deve projetar suas interfaces de modo que todos os danos causados ​​por dados defeituosos afetem apenas o usuário que os envia.

Answer 3

O que há de errado com Autenticação HTTP Digest?

Answer 4

Há uma discussão melhor sobre isso aqui:

Melhores práticas para proteger um serviço de API / Web REST