OAuth de duas pernas - procurando informações

votos
25

Eu quero implementar um novo baseado em REST API em nossa infra-estrutura, e 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, nós 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 este? 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 APIs somente de usuário.

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 o consumidor eo prestador de serviços de existir neste cenário. O usuário final não vêm para jogar!

Publicado 19/05/2009 em 21:46
fonte usuário
Em outras línguas...                            


3 respostas

votos
48

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, que 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ê usará o método de assinatura HMAC-SHA1) 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, 2-legged OAuth apenas especifica uma forma de "sinal" (calcular um hash mais) vários campos que incluem a data atual, um número aleatório chamado de "nonce", e os parâmetros do seu pedido. Isto torna muito difícil para representar os pedidos para o 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 seria inicialmente quiser 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!

Respondeu 06/06/2009 em 08:02
fonte usuário

votos
5

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

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

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

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

  1. Tudo termina 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 com mais freqüência.

  3. Como 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.
Respondeu 19/05/2009 em 22:02
fonte usuário

votos
2

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 ..

Respondeu 10/06/2009 em 21:49
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more