新しいサーバー間 API を実装する場合、他のユーザーが簡単に使用できるようにするために、どの認証標準を使用できますか?
理想的には、認証がどのように機能するかについて文書化する必要が少ないほど (したがって標準)、サービスを利用する開発者が標準ライブラリを使用できる可能性が高くなります。
ただし、いくつかの制限があります。
- API が HTTPS で利用できるかどうかは保証できません。複数の Web サイト (1 つの IP アドレスを持つ) をホストしているボックス上にある可能性があるためです。
- リプレイ攻撃をブロックする必要があります...そのため、リクエストがネットワーク上の別のノードによってキャプチャされた場合、同じリクエストを API に再送信することはできません。
- 理想的には、リクエストを送信してレスポンスを返すだけでよいので、最初に API に接続してワンタイム キー (ノンス) を取得する必要はありません。
- 中間者タイプの攻撃を避けるために、リクエストはおそらく送信者によって全体的に署名されている必要があります。
SSL タイプのセットアップは少し複雑すぎるのではないかと思います。ほとんどの開発者は SSL を適切に実装する方法を本当に知らないようです。
oAuth 1.0 では、かなり単純に見えます:
http://provider.example.net/profile
Authorization: OAuth realm="http://provider.example.net/",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_signature_method="HMAC-SHA1",
oauth_signature="IxyYZfG2BaKh8JyEGuHCOin%2F4bA%3D",
oauth_timestamp="1191242096",
oauth_token="",
oauth_nonce="kllo9940pd9333jh",
oauth_version="1.0"
しかし、開発者は現在 oAuth 2 に注目しているようで、考えられる解決策の 1 つは次のとおりです。
2-legged oauth は OAuth 2.0 でどのように機能しますか?
最初に「/oauth/token」を呼び出してトークンを取得する必要がありますが、これが実際にどのように機能するかについての仕様の形式はあまりないようです (返信を参照)。
http://www.ietf.org/mail-archive/web/oauth/current/msg07957.html
ただし、oAuth 2 で MAC を使用することについての言及がいくつかあります。これは役立つ可能性があります。たとえば、認証を 1 回行って MAC を取得し (ログインの詳細なしで)、この半永久的に保持し、その後のすべてに再利用します。リクエスト：
http://blog.facilelogin.com/2013/01/oauth-20-bearer-token-profile-vs-mac.html
HMAC についての興味深い議論もあります。これは、これがどのように機能するかについての標準がないことを意味します。
http://flascelles.wordpress.com/2010/01/04/standardize-hmac-oauth-restful-authentication-schemes/
その他の注意事項:
oAuth 1.0 の実装、ドキュメント、およびディスカッション:
http://www.ietf.org/mail-archive/web/oauth/current/msg06218.html https://developers.google.com/accounts/docs/OAuth#GoogleAppsOAuth http://oauth.googlecode.com/ svn/spec/ext/consumer_request/1.0/drafts/2/spec.html
残念ながら、oAuth 2.0 について読めば読むほど、Eran Hammerに同意するようになりました。
現在提供されているのは、「コンサルティング サービスと統合ソリューションを販売するためのまったく新しいフロンティア」を提供する、「エンタープライズ向け」の承認プロトコルの青写真です。 http://en.wikipedia.org/wiki/OAuth