Protegendo minha API REST com OAuth e ainda permitindo autenticação através de provedores OAuth de terceiros (usando DotNetOpenAuth)

Eu tenho um produto com uma API REST direta para que os usuários do produto possam se integrar diretamente aos recursos do produto sem usar minha interface com o usuário da web.

Recentemente, tenho recebido interesse de vários terceiros sobre a integração de seus clientes de desktop com a API para permitir que os usuários do meu produto acessem seus dados usando esse aplicativo de terceiros.

Vi que os aplicativos que desejam usar o Twitter se autenticam usando uma página de login hospedada pelo Twitter que concede permissão a um aplicativo específico para acessar os dados desse usuário. Você clica no botão "Permitir" ou "Negar" e o processo de autenticação está concluído. O Facebook usa o mesmo mecanismo que eu posso dizer.

Após uma pesquisa mais aprofundada, parece que o OAuth está em ação e, como minha API é baseada em .Net, acho que devo usar o DotNetOpenAuth e fornecer um mecanismo semelhante. Infelizmente, os exemplos são escassamente documentados (se houver) e os únicos tutoriais que posso encontrar on-line parecem focados em ajudá-lo a fornecer um mecanismo de login para seus usuários, para que possam fazer login no seu site usando um provedor de terceiros.

O que eu realmente gostaria de fazer é que minha API REST lide com toda a autenticação principal e lógica de negócios do meu aplicativo Web e tenha, sob o capô, meu aplicativo Web essencialmente outro aplicativo que apenas usa a API via OAuth. Os usuários se autenticariam no site usando diretamente seu nome de usuário e senha ou através de um provedor terceirizado como MyOpenID ou Facebook e, em seguida, o site usaria de alguma forma o token retornado para se autenticar na API REST.

Basicamente, parece que eu preciso da minha API para hospedar um serviço OAuth, mas também os usuários usam um serviço OAuth de terceiros. Não posso deixar de pensar que não tenho o suficiente conhecimento do OAuth para decidir se estou complicando demais as coisas ou se o que estou tentando fazer é uma maneira boa ou ruim de fazer as coisas.

Alguém pode me dar pelo menos uma ampla visão geral das etapas que preciso executar ou o que devo considerar para que isso aconteça? Ou me aponte para alguns tutoriais? Ou exploda a minha proposta e diga que estou errado (arquitetonicamente) sobre isso?

Primeiro, gostaria de enfatizar a diferença entre autenticação e autorização:

Um usuário se autentica no seu site fornecendo algumas credenciais, como nome de usuário + senha. O OpenID permite que isso seja deslocado, fazendo com que o usuário se autentique em outro serviço, que então afirma a identidade do usuário no seu site em nome do usuário. Seu site confia no serviço de terceiros (o provedor OpenID) e, portanto, considera o usuário conectado.

Um serviço ou aplicativo não se autentica no seu site - pelo menos normalmente não. Um usuário autoriza um serviço ou aplicativo a acessar os dados do usuário. Isso geralmente é feito pelo aplicativo que solicita autorização do provedor de serviços e, em seguida, envia o usuário ao provedor de serviços, onde o usuário se autentica primeiro (para que o provedor saiba com quem está falando) e depois diz ao site "sim, não há problema em [aplicativo] acessar meus dados [de alguma maneira restrita] ". A partir de então, o aplicativo usa um token de autorizaçãopara acessar os dados do usuário no site do provedor de serviços. Observe que o aplicativo não se autentica como se fosse o usuário, mas usa outro código para garantir ao serviço que está autorizado a acessar os dados de um usuário específico.

Portanto, com essa distinção esclarecida, você pode tomar decisões em seu site sobre autenticação e autorização de forma totalmente independente. Por exemplo, se você deseja que seus usuários possam fazer login com todos: nome de usuário + senha, OpenID e Facebook, você pode fazer isso. Uma decisão completamente ortogonal é como você autoriza aplicativos (existem muitos protocolos que você pode usar para isso, é claro que o OAuth é bastante popular).

O OpenID está focado na autenticação do usuário . OAuth está focado na autorização do aplicativo . No entanto, alguns serviços, como o Facebook e o Twitter, optaram por usar o OAuth para autenticação e autorização, em vez de usar o OpenID para autenticação e o OAuth para autorização.

Agora, para o seu próprio projeto, recomendo fortemente que você verifique o modelo de projeto do site ASP.NET MVC 2 OpenID (C #) disponível na VS Gallery. Pronto para uso, vem com autenticação OpenID e suporte ao provedor de serviços OAuth. Isso significa que seus usuários podem efetuar login com o OpenID e aplicativos e serviços de terceiros podem usar o OAuth para fazer chamadas de API ao seu site e acessar dados do usuário.

O que parece que você gostaria de adicionar a este modelo de projeto depois de começar é a capacidade de seus usuários efetuarem login com nome de usuário + senha e OpenID. Além disso, se você deseja que o Facebook e o Twitter sejam uma opção para seus usuários, também deve implementá-los, pois eles não usam o padrão OpenID. Mas o download do DotNetOpenAuth inclui exemplos para fazer login no Twitter e no Facebook, para que você tenha algumas orientações.

Eu suspeito que você não terá muito ou nada a fazer na frente de autorização. Ele vem com o OAuth, como eu disse antes, e isso provavelmente será suficiente para você.

Em primeiro lugar. Você precisa separar mentalmente qual é a sua API - dos métodos de autenticação.

Sua API é basicamente recursos e métodos para manipular esses recursos. E você pode ter vários métodos para autenticar o acesso à sua API.

OAuth é um desses mecanismos de autenticação. Ser um provedor OAuth é ótimo, mesmo que a especificação seja um pouco difícil de entender, especialmente as partes que têm a ver com assinaturas. Depois de instalar o OAuth, os aplicativos clientes costumam se autenticar com facilidade, pois existem muitas bibliotecas de "código aberto, já concluídas, apenas implementam" disponíveis na maioria dos idiomas.

Os prós e contras do OAuth foram debatidos por um tempo. Mas, para formar sua própria opinião, sugiro a leitura deste guia definitivo, escrito por Eran Hammer-Lahav , uma das pessoas responsáveis ​​pela especificação do OAuth.

As únicas alternativas reais ao OAuth, até onde eu vejo, são o OAuth 2.0 e apenas uma autenticação básica simples.

Fora isso, você está falando sobre a autenticação usando o Open-ID ou a identidade do Facebook, etc. Essa é outra pergunta que você deve se perguntar. Mas está realmente fora do escopo das APIs e do OAuth. Para mim, isso parece mais uma questão de criação de usuários em seu serviço. Eu posso estar errado.