（DotNetOpenAuthを使用して）サードパーティのOAuthプロバイダーによる認証を許可しながら、OAuthでREST APIを保護する

製品のユーザーがWebユーザーインターフェイスを使用せずに製品の機能と直接統合できるように、単純なREST APIを備えた製品があります。

最近、さまざまなサードパーティから、デスクトップクライアントとAPIを統合して、私の製品のユーザーがそのサードパーティのアプリケーションを使用してデータにアクセスできるようにすることに関心を示しています。

Twitterを使用したいアプリケーションは、Twitterがホストするログインページを使用して認証を行い、そのユーザーのデータにアクセスするための特定のアプリケーション権限を付与します。「許可」または「拒否」ボタンをクリックすると、認証プロセスが完了します。Facebookは私が言うことができる最高のメカニズムを使用しています。

さらなる調査の結果、これは実際のOAuthのようであり、私のAPIは.Netベースであるため、DotNetOpenAuthを使用して同様のメカニズムを提供する必要があると考えています。残念ながら、サンプルはまばらに文書化されており（もしあれば）、オンラインで見つけることができる唯一のチュートリアルは、サードパーティのプロバイダーを使用してユーザーがWebサイトにログインできるように、ユーザーにログインメカニズムを提供するのに役立つことに集中しているようです。

私が本当にやりたいことは、REST APIでWebアプリケーションのすべてのコア認証とビジネスロジックを処理し、内部的には、OAuthを介してAPIを使用するだけのアプリケーションです。ユーザーは、ユーザー名とパスワードを直接使用するか、MyOpenIDやFacebookなどのサードパーティプロバイダーを介してWebサイトで認証し、Webサイトは返されたトークンを使用してREST APIに対して認証を行います。

基本的に、OAuthサービスをホストするためにAPIが必要であるように見えますが、ユーザーにサードパーティのOAuthサービスを使用させる必要もあります。どうしようもないのですが、OAuthを十分に理解していないので、複雑すぎたり、やろうとしていることが良い方法か悪い方法かを判断できません。

誰かが、少なくとも私が実行する必要のある手順の概要、またはこれを実現するために何を見る必要があるかを教えてもらえますか？または、いくつかのチュートリアルを教えてください。または私の提案を爆破し、私はこれについて（アーキテクチャ的に）すべて間違っていると言っていますか？

最初に、認証と承認の違いを強調します。

ユーザーのユーザー名+パスワードとして、いくつかの資格等を供給することにより、あなたのウェブサイトへの認証を行います。OpenIDを使用すると、ユーザーに別のサービスへの認証を要求し、ユーザーに代わってユーザーのIDをWebサイトにアサートすることで、これを排除できます。サイトはサードパーティサービス（OpenIDプロバイダー）を信頼しているため、ユーザーがログインしていると見なされます。

サービスまたはアプリケーションが Webサイトに認証されない-少なくともない一般的。ユーザーは、サービスまたはアプリケーションにユーザーのデータへのアクセスを許可します。これは通常、アプリケーションがサービスプロバイダーの承認を要求し、ユーザーをサービスプロバイダーに送信することで行われます。サービスプロバイダーはユーザーを最初に認証し（サービスプロバイダーが誰と話しているのかを知るため）、次にユーザーはサイトに「はい、 [アプリケーション]が私のデータに[制限された方法で]アクセスしても問題ありません。それ以降、アプリケーションは認証トークンを使用しますサービスプロバイダーサイトのユーザーデータにアクセスします。アプリケーションはユーザーであるかのように自身を認証するのではなく、別のコードを使用して、特定のユーザーのデータへのアクセスが承認されていることをサービスに保証することに注意してください。

したがって、その区別を明確にすると、認証と承認について完全に独立してサイトで決定を下すことができます。たとえば、ユーザーがユーザー名+パスワード、OpenID、Facebookのすべてを使用してログインできるようにしたい場合は、これを行うことができます。完全に直交する決定は、アプリケーションを承認する方法です（このために使用できるプロトコルは多数あり、OAuthはもちろん非常に人気があります）。

OpenIDはユーザー認証に重点を置いています。OAuthはアプリケーションの承認に重点を置いています。ただし、FacebookやTwitterなどのいくつかのサービスでは、認証にOpenIDを使用し、承認にOAuthを使用する代わりに、認証と承認にOAuthを使用することを選択しています。

自分のプロジェクトの場合は、VS Galleryから入手できるASP.NET MVC 2 OpenID Webサイト（C＃）プロジェクトテンプレートをチェックすることを強くお勧めします。OpenID認証と OAuthサービスプロバイダーのサポートが標準で付属しています。つまり、ユーザーはOpenIDを使用してログインでき、サードパーティのアプリケーションやサービスはOAuthを使用してWebサイトへのAPI呼び出しを行い、ユーザーデータにアクセスできます。

いったんこのプロジェクトテンプレートに追加したいのは、ユーザーがユーザー名+パスワードとOpenIDでログインできるようにすることです。また、FacebookやTwitterをユーザーのオプションにしたい場合は、OpenID標準を使用しないため、ユーザーもそれを実装する必要があります。ただし、DotNetOpenAuthのダウンロードには、TwitterおよびFacebookでログインするためのサンプルが含まれているので、そこにいくつかのガイダンスがあります。

認可の面でやるべきことはほとんどないと思います。前に言ったように、OAuthが付属しており、おそらくそれで十分でしょう。

まず第一に。APIとは何かを、認証方法から精神的に分離する必要があります。

APIは基本的にリソースであり、それらのリソースを操作するためのメソッドです。また、APIへのアクセスを認証する方法はいくつかあります。

OAuthはそのような認証メカニズムの1つです。OAuthプロバイダーであることは素晴らしいことですが、仕様、特に署名に関係する部分は少しわかりにくいです。OAuthを導入すると、ほとんどの言語で利用可能な「オープンソース、すでに実装済み、実装済み」のライブラリーが非常に多いため、クライアントアプリケーションは通常、簡単に認証できます。

OAuthの長所と短所はしばらくの間議論されてきました。しかし、あなた自身の意見を形成するために、私はOAuth仕様の責任者の一人であるEran Hammer-Lahavによって書かれたこの決定的なガイドを読むことをお勧めします。

私が見る限り、OAuthの真の代替手段は、OAuth 2.0と単純な基本認証だけです。

それ以外には、Open-IDやFacebookのIDなどを使用した認証について話しています。これは、自問する必要のあるもう1つの質問です。しかし、それは実際にはAPIとOAuthの範囲外です。私にとって、それはあなたのサービスにおけるユーザー作成の問題のより多くを感じます。私は間違っているかもしれません。