Como garantir serviços Web RESTful?

Tenho de implementar serviços web seguros . Já fiz alguma pesquisa com o Google, mas estou preso.

Opções:

TLS (HTTPS) +

 Há mais opções possíveis a considerar? Se OAuth então que versão? Isso importa? Pelo que li até agora OAuth 2.0 com tokens ao portador (isto é, sem assinaturas) parece serinseguro .

encontrei outro artigo muito interessante sobreautenticação baseada no resto .

protege a tua API de descanso... O Caminho Certo

Author: Community, 2011-01-27
Source

3 answers

Há outro método muito seguro. São certificados de cliente. Sabe como os servidores apresentam um certificado de SSL quando os contacta em https? Os servidores podem pedir cert a um cliente para saberem que o cliente é quem dizem ser. Os clientes geram certs e dão - nos através de um canal seguro (Como entrar no seu escritório com uma chave USB-de preferência uma chave USB não-trojanada).

Carrega a chave pública do certificado de cliente (e do seu signatário) certificados, se necessário) no seu servidor web, e o servidor web não aceita ligações de ninguém excepto as pessoas que têm as chaves privadas correspondentes para as certs que conhece. Ele corre na camada HTTPS, então você pode até mesmo ser capaz de ignorar completamente a autenticação de nível de aplicação como OAuth (dependendo de seus requisitos). Você pode abstrair uma camada de distância e criar uma autoridade de certificado local e assinar os pedidos de Cert dos clientes, permitindo-lhe saltar a ' make eles vêm para o escritório' e 'carregar certs para os degraus do servidor'.

Dói-te o pescoço? Absolutamente. Bom para tudo? Nao. Muito seguro? Sim. No entanto, depende do facto de os clientes manterem os seus certificados seguros (não podem publicar as suas chaves privadas online), e normalmente é usado quando se vende um serviço a clientes em vez de deixar qualquer um registar-se e ligar-se. [[1]de qualquer forma, pode não ser a solução que você está procurando( provavelmente não é para ser honesto), mas é outra Opcao.
 56
Author: Tom Ritter, 2011-01-27 17:04:01

HTTP Basic + HTTPS é um método comum.

 17
Author: pc1oad1etter, 2011-01-27 16:46:21

Se escolher entre as versões do OAuth, vá com o OAuth 2.0.

Os tokens Portadores de OAuth só devem ser usados com um transporte seguro.

Os tokens Portadores de OAuth são tão seguros ou inseguros como o transporte que encripta a conversa. HTTPS cuida de proteger contra ataques de repetição, por isso não é necessário que o token portador também se proteja contra o replay. Embora seja verdade que, se alguém intercepta o seu símbolo, pode fazer-se passar por si ao chamar o API, há muitas maneiras de mitigar esse risco. Se você der aos seus tokens um longo período de validade e esperar que os seus clientes armazenem os tokens localmente, você tem um maior risco de tokens sendo interceptados e usurpados do que se você der aos seus tokens um curto prazo de validade, exigir que os clientes adquiram novos tokens para cada sessão, e aconselhar os clientes a não persistir tokens.

Se você precisa proteger cargas que passam através de vários participantes, então você precisa de algo mais do que HTTPS / SSL, uma vez que o HTTPS/SSL só encripta uma ligação do grafo. Isto não é culpa de OAuth.

Os tokens ao portador são fáceis de obter para os clientes, fáceis de usar para as chamadas API e são amplamente utilizados (com HTTPS) para proteger as API do Google, Facebook e muitos outros serviços.

 8
Author: dthorpe, 2013-04-17 19:23:24