19

REST APIの認証を実装するためのベストプラクティスは何ですか？

BASIC auth + SSLまたはhttps://datatracker.ietf.org/doc/html/draft-hammer-http-token-auth-01のようなものを使用していますか？

利用可能な既存のソリューションはありますか（.NET / WebApi用）？

4

3 に答える 3

35

これに対する答えは、Web APIの対象者と、正確に認証する対象によって異なります。

  • Apiを使用するクライアントアプリケーションを認証しますか？
  • アプリケーションからユーザーを認証して、クライアントアプリケーション内で（Apiを使用して）データを取得しますか？
  • または、クライアントアプリケーションとクライアントアプリケーションを使用するユーザーの両方を認証しますか？

認証する対象に応じて、複数のオプションがあります。ただし、所有するものを再発明するよりも、多くのクライアントライブラリが利用できる固溶体を使用する方がよいことを常に念頭に置いてください。これから少し離れることはありませんが、独自の方法で、認証の1つの方法を選択し、それに固執し、クライアントライブラリを壊さないでください。

基本認証：実装は非常に簡単ですが、ユーザーではなく、それを使用してクライアントアプリを認証します。この種の認証は、ビジネスの信頼関係が必要であり、認証と安全性が最初の関心事ではない場合に便利です。ただし、APIで特定のユーザーへの呼び出しを追跡する方法はなく、クライアントアプリケーションだけです。もちろん、ユーザーのユーザー名とパスワードをクライアントアプリケーションに保存することもできますが、これは1つの方法ではなく悪い習慣です。

トークンベースの認証：トークン認証にはさまざまな方法がありますが、ここで説明しているのは、ユーザーがApiにアクセスするためにクライアントアプリケーションにコピーするユーザー用の単一のトークンです。このようにして、ユーザー（私のApiでこの呼び出しを行ったユーザー）を認証できます。また、作成と使用はかなり簡単です。撤回は、それが最も安全な方法ではなく、ユーザーの操作が必要であり、ユーザーが複数のアプリケーションでApiトークンを使用する可能性があることです。この認証方法を基本認証で拡張して、クライアントを認証することができます。したがって、clientid +clientsecret+トークンでユーザーを識別します。ただし、これを実現したい場合は、Oauth2を確認することをお勧めします。

OAuth2：認証に対するフルアクセスが必要な場合は、この方法を使用できます。これはおそらく最も将来性のある方法ですが、最も多くの作業が必要です（少なくとも、IDプロバイダー/リソースプロバイダー側​​で。クライアントアプリケーションは、利用可能な多くのクライアントライブラリを使用してこれを実装するのにかなり簡単です。この認証方法（トークンベース）では、ユーザーのユーザー名とパスワードを共有しなくても、クライアントとユーザーを認証できます。

私の推奨事項：これがあなたのケースに合うなら、基本認証を使うことです、それは簡単で、HTTPSと一緒にするとかなり安全です。それが適合しない場合は、Oauth2を使用します。これは、最も堅実で使用されている標準（Instagram / Google / Facebook ）であり、自由度が高く、エコシステムが成長するにつれて、実装がより簡単になります。結局のところ、APIを実装している人にとっては、何かを学びOauth 2.0、それからjgauffin物事のやり方を学ぶ方がはるかに興味深いのです。

参考： Apigeeのウェブサイトもご覧ください。Apiは彼らのビジネスであり、かなり興味深い読み物があります。それらの1つは、無料の電子ブックです。Oauthの全体像には、本当にOauthが必要かどうかを尋ねる興味深い段落もあります。（16ページから-APIセキュリティに必要なのはOAuthだけですか？）

サーバー間APIの場合-少数のサーバーのみが使用するように設計されたAPI-OAuthはやり過ぎです。アプリごとに個別の認証クレデンシャルのセットを持つことはOAuthの優れた機能ですが、サーバー間で使用するには、ブラウザーを使用して安全にログインするか、OAuthの「ダンス」に他の手順を実装する必要があります。道。代わりに、HTTP基本認証などの単純なセキュリティ標準を使用し、各アプリに一意のパスワードを割り当てるだけで十分です。双方向SSLは、より強力で追跡可能な認証という利点がある、面倒なアプローチではありますが、もう1つの優れたアプローチです。ただし、先を考えてください。それらのAPIは本当にサーバーによって永久に使用されるだけですか？

既存のソリューション：特権を最小限に抑える方法が何であれ、ドミニク・ベイヤーと彼のnugetパッケージは、優れた有利なスタートを切ることができます。彼のIdentitymodelbasic authenticationを使用した実装は本当に簡単です。また、すぐに使用できるIDサーバーにトークンを提供したい場合は、考えられるすべてのことを実行する彼のIDサーバーを確認してください。ただし、 DotnetOpenAuthは（私見）もう少し構成可能で、自分のように微調整するのが簡単なので、私もDotnetOpenAuthを検討しますが、より多くの作業が必要になります。Oauth2

于 2013-02-21T13:42:11.353 に答える
2

Security Token ServiceまたはSTSを調べる必要があります。

詳細については、次のリンクを確認してください。

ASP.NETメンバーシッププロバイダーを使用する既製のセキュリティトークンサービス（STS）？

http://msdn.microsoft.com/en-us/library/ee517259.aspx

于 2013-02-21T07:27:45.633 に答える
0

ここをご覧ください。IdentityModelはWebAPIをサポートしています。

http://thinktecture.github.com/Thinktecture.IdentityModel.45/

于 2013-02-21T12:35:33.297 に答える