REST APIをOAuthで保護しながら、サードパーティOAuthプロバイダーを介した認証を許可する（DotNetOpenAuthを使用）
Webユーザーインターフェイスを使用せずに製品のユーザーが製品の機能と直接統合できるように、単純なREST APIを備えた製品を所有しています。
最近、デスクトップクライアントをAPIと統合して、製品のユーザーがそのサードパーティアプリケーションを使用してデータにアクセスできるようにすることについて、さまざまなサードパーティから関心を集めています。
Twitterを使用したいアプリケーションは、特定のアプリケーションにそのユーザーのデータへのアクセス許可を与えるTwitterがホストするログインページを使用して認証することを見てきました。 「許可」または「拒否」ボタンをクリックすると、認証プロセスが完了します。 Facebookは、私が知る限り、同じメカニズムを使用しています。
さらに調査すると、これはOAuthのように見え、私のAPIは.Netベースであるため、DotNetOpenAuthを使用して同様のメカニズムを提供する必要があると考えています。残念ながら、サンプルはほとんど文書化されておらず、オンラインで見つけることができる唯一のチュートリアルは、サードパーティプロバイダーを使用してWebサイトにログインできるように、ユーザーにログインメカニズムを提供することに焦点を当てているようです。
本当にしたいことは、私のREST APIがWebアプリケーションのすべてのコア認証とビジネスロジックを処理し、Webアプリケーションが基本的にOAuth経由でAPIを使用するだけの別のアプリケーション。ユーザーは、ユーザー名とパスワードを直接使用して、またはMyOpenIDやFacebookなどのサードパーティプロバイダーを介してWebサイトで認証し、Webサイトは何らかの方法で返されたトークンを使用してREST APIに対して認証します。
基本的に、何らかの方法でOAuthサービスをホストするためにAPIが必要なようですが、ユーザーにサードパーティOAuthサービスを使用させることもできます。仕方がありませんが、OAuthを十分に把握していないので、物事を複雑にしすぎているのか、やろうとしているのが良いか悪いのかを判断できませんもの。
誰かが私が着手する必要があるステップの少なくとも大まかな概要を教えてもらえますか、またはこれを実現するために私が見なければならないことはありますか？または、いくつかのチュートリアルを教えてください。または私の提案を爆発させて、私はこれについて（アーキテクチャ上）すべて間違っていると言っていますか？
最初に、認証と承認の違いを強調したいと思います。
userは、ユーザー名+パスワードなどの資格情報を提供することにより、Webサイトに対して認証を行います。 OpenIDでは、ユーザーを別のサービスに認証することでこれを置き換えることができます。次に、ユーザーに代わってユーザーのIDをWebサイトにアサートします。サイトはサードパーティのサービス（OpenIDプロバイダー）を信頼しているため、ユーザーがログインしていると見なします。
serviceまたはapplicationはWebサイトに対して認証されません-at少なくとも普通ではありません。ユーザーは、ユーザーのデータにアクセスするサービスまたはアプリケーションを許可します。これは通常、アプリケーションがサービスプロバイダーの承認を要求し、ユーザーをサービスプロバイダーに送信することで行われます。ユーザーは最初に認証を行い（サービスプロバイダーは通話相手を知る）、ユーザーはサイトに「はい、 [アプリケーション]が[制限された方法で]私のデータにアクセスしても問題ありません。」それ以降、アプリケーションは許可トークンを使用して、サービスプロバイダーサイトのユーザーデータにアクセスします。アプリケーションは、ユーザーであるかのように自身を認証しませんが、特定のユーザーのデータへのアクセスが許可されていることをサービスに保証するために別のコードを使用します。
その区別を明確にすると、サイトで認証と承認について完全に独立して決定を下すことができます。たとえば、ユーザーがユーザー名+パスワード、OpenID、Facebookのすべてでログインできるようにする場合は、それを実行できます。完全に直交する決定は、アプリケーションを許可する方法です（このために使用できるプロトコルは多数あり、OAuthはもちろん非常に人気があります）。
OpenIDはユーザー認証に焦点を当てています。 OAuthはアプリケーションに焦点を合わせています承認。ただし、FacebookやTwitterなどのいくつかのサービスは、認証にOpenIDを使用する代わりに、認証and承認にOAuthを使用することを選択しました。 OAuth承認用。
自分のプロジェクトについては、VS Galleryから入手できる ASP.NET MVC 2 OpenID Webサイト（C＃） プロジェクトテンプレートを確認することを強くお勧めします。すぐに使えるOpenID認証andOAuth Service Providerサポートが付属しています。つまり、ユーザーはOpenIDでログインでき、サードパーティのアプリケーションとサービスはOAuthを使用してWebサイトにAPI呼び出しを行い、ユーザーデータにアクセスできます。
このプロジェクトテンプレートに追加したいのは、ユーザーがOpenIDだけでなくユーザー名+パスワードでログインできることです。また、FacebookとTwitterをユーザーのオプションにしたい場合は、OpenID標準を使用しないため、同様にそれを実装する必要があります。ただし、DotNetOpenAuthのダウンロードには、TwitterとFacebookでログインするためのサンプルが含まれているため、そこにいくつかのガイダンスがあります。
認可の面で何かすることがあるとしても、あなたはあまり多くないでしょう。以前に言ったように、OAuthが付属しているので、おそらくそれで十分でしょう。
まず第一に。認証方法から、APIとは何かを精神的に分離する必要があります。
APIは基本的にリソースであり、それらのリソースを操作するメソッドです。また、APIへのアクセスを認証するいくつかの方法を使用できます。
OAuthはそのような認証メカニズムの1つです。 OAuthプロバイダーであることは、仕様、特に署名に関係する部分を理解するのが少し難しくても、素晴らしいです。 OAuthを配置すると、ほとんどの言語で利用できる「オープンソース、既に完了、実装のみ」のライブラリが非常に多くあるため、クライアントアプリケーションの認証は簡単になります。
OAuthの長所と短所はしばらく議論されてきました。しかし、あなた自身の意見を形成するために、 この決定的なガイド、Eran Hammer-Lahavによって書かれた 、OAuth仕様の責任者の一人を読むことをお勧めします。
私が見る限り、OAuthの唯一の本当の代替は、OAuth 2.0と単なる基本認証です。
それ以外は、Open-IDやfacebook identityなどを使用して認証することです。これは、あなたが自問する必要があるもう1つの質問です。しかし、実際にはAPIとOAuthの範囲外です。私にとって、それはあなたのサービスでのユーザー作成の問題のように感じます。私は間違っているかもしれません。