OAuth de duas pernas - procurando informações

Question

Eu quero implementar um API em nossa infra-estrutura, e baseada em REST novo OAuth parece ser o caminho a percorrer.

Para a nossa aplicação, haverá primeiro ser apenas o acesso ao servidor para servidor, que será completamente irrestrito. Eu acredito que este é chamado de autorização de duas pernas.

Mais tarde, gostaríamos de permitir que a API para ser consumido pelo navegador, que irá transformar a nossa autorização em três pernas.

Existe um bom ponto de partida para implementar esta começando? Como podemos autorizar totalmente um servidor e para baixo da estrada adicionar autorização restrito por usuário?

A especificação OAuth não é realmente útil nessas situações, mas acredito que isso implica que precisamos para criar uma sessão nunca expirar para o acesso ao servidor para servidor, e mais tarde adicionar sessões normais com acesso limitado para o usuário somente APIs.

Estou na esperança de encontrar pontos de partida para mais informações, me avise!

É OAuth para mim? Eu só estou procurando um sistema de solicitação autenticado, e somente a exist provedor de consumidor e serviço neste cenário. O usuário final não vêm para jogar!

Answer 1

OAuth vai acabar sendo muito difícil para as nossas necessidades. Eu decidi adotar esquema de autenticação do Amazon S3, simplesmente porque ele se encaixa em nosso modelo melhor.

Obrigado por ajudar a encontrar uma resposta embora ..

Answer 2

Ya, OAuth é provavelmente para você.

Na verdade, existem duas especificações OAuth, a versão 3-legged e a versão 2-legged. A versão 3-legged é a que recebe a maior parte da atenção, e é não o que você deseja usar.

A boa notícia é que a versão 2-legged faz exatamente o que você quer, ele permite que um aplicativo para conceder acesso a outro, quer através de uma chave secreta compartilhada (muito semelhante ao modelo de serviço Web da Amazon, você vai usar o HMAC-SHA1 método de assinatura) ou através de um sistema público / privado chave (uso de método de assinatura: RSA-SHA1). A má notícia, é que não é tão bem suportado ainda que a versão 3-legged ainda, então você pode ter que fazer um pouco mais trabalho do que de outra forma poderia ter de agora.

Basicamente, OAuth 2-legged apenas especifica uma forma de "sinal" (calcular um hash over) vários campos que incluem a data atual, um número aleatório chamado de "nonce", e os parâmetros do seu pedido. Isso torna muito difícil a pedidos personificar a seu serviço web.

OAuth é lenta mas seguramente, se tornando um padrão aceito para este tipo de coisa -. Você vai ser melhor no longo prazo, se você aceitá-lo, porque as pessoas podem aproveitar as diversas bibliotecas disponíveis para fazer isso

É mais elaborado do que o inicialmente iria querer entrar - mas a boa notícia é que um monte de gente já passou muito tempo com isso para que você saiba que você não esqueceu nada. Um grande exemplo é que muito recentemente Twitter, descobriu um buraco na segurança OAuth que a comunidade está trabalhando atualmente em fechamento. Se você tivesse inventado o seu próprio sistema, você está tendo que descobrir tudo isso em seu próprio país.

Boa sorte!

Answer 3

Lembre-se de distinguir entre autenticação e autorização. Em alguns lugares, acredito que as misturas OP os dois.

Por exemplo, uma vez por autentica servidor alguém, geralmente implícita ou explicitamente (usando cookies) fornece um token de autenticação para que os pedidos posteriores já estão autorizados.

Cabe ao servidor quanto tempo as credenciais durar. Ele é inteligente para plano que as credenciais tempo limite em algum ponto. Apenas ter o servidor cliente estar preparado para re-autenticar-se sempre que recebe a "autorização expirou" erro resposta.

Você não quer tentar fornecer uma sessão de "nunca expirar" desde que:

1. Tudo expira em algum ponto. Por exemplo, como é que o servidor do cliente ser capaz de começar a acessar o aplicativo novamente se ficar sem energia ou é reiniciado?

2. Você está criando um sistema inflexível. Eles tendem a quebrar mais vezes.

3. Uma vez que você sabe que você deseja adicionar outros tipos de logins no futuro, em vez de dois tipos de logins (clientes de servidores e clientes do navegador), fazer apenas um tipo de logon agora. O trabalho adicional para o servidor do cliente será a implementação de um "re-login, se necessário" capacidade.