2

背景：私はnode.jsとexpressを使用してAPIを作成しています。標準のコンシューマー/ユーザーキー/シークレット方式（Twitter、Facebookなどと同じ方法）でAPIサーバーにOAuthを実装しました。これらの一般的なAPIと同じ方法で、サードパーティが私のAPIに接続することを期待しています。

通常、クライアントはアプリケーショントークン/シークレットに接続します（たとえば、Facebook開発者としてFacebookアプリを作成すると、これらが提供されます）。ただし、コードが安全でない方法で実装されているために、クライアントがアプリケーションのシークレットを提供できない場合があります。具体的には、Javascriptライブラリを参照しています。たとえば、開発者は、アプリケーションシークレットがプレーンテキストであり、悪意のあるユーザーによって読み取られる可能性があるため、Javascriptコードでアプリケーションシークレットを公開することを望んでいません。

Facebookがこの問題を回避していることに気づきました。開発者は、アプリケーショントークン（シークレットではない）のみをJavascriptライブラリに提供する必要があります。ライブラリを根本的に安全でなくして、APIに同様のオプションを提供する方法がわかりません。つまり、安全性の高いトークン/シークレットを提供せずにJavascriptクライアントライブラリからAPIに対してリクエストが行われている場合、それらのリクエストはOAuth APIによってどのように認証されますか？

知的に、私が考えることができる最善の解決策は、ライブラリが使用する秘密を返すために、HTTPS接続を介してJavascriptクライアントライブラリとAPIサーバーの間で何らかのトークンハンドオフを行うことです。ただし、なりすましを防ぐためにこのハンドオフをどのように保護するかはよくわかりません。

4

1 に答える 1

2

ほとんどの場合、カスタムの方法を実装するよりも、標準に従う方が適切です。OAuth2は、承認付与フローを実行するために、最新のドラフト（28）で4つのメソッドを指定しています。暗黙のフローは、Facebookで見たものです。

標準がそれについて言うように：

暗黙の許可フロー中にアクセストークンを発行する場合、許可サーバーはクライアントを認証しません。場合によっては、クライアントIDは、アクセストークンをクライアントに配信するために使用されるリダイレクトURIを介して検証できます。アクセストークンは、リソース所有者またはリソース所有者のユーザーエージェントにアクセスできる他のアプリケーションに公開される場合があります。

暗黙的な付与は、アクセストークンを取得するために必要なラウンドトリップの数を減らすため、一部のクライアント（ブラウザー内アプリケーションとして実装されたクライアントなど）の応答性と効率を向上させます。ただし、この利便性は、特に認証コードの付与タイプが使用可能な場合に、暗黙的な付与を使用することによるセキュリティへの影響と比較検討する必要があります。

いくつかのセキュリティ上の欠点があります。

しかし、私が見る限り、他の方法はクライアント（サードパーティのWebサイト所有者）またはリソース所有者（ユーザー）のいずれかに秘密を公開しているため、機能しません。したがって、これを維持する必要があります。

于 2012-07-09T18:23:47.180 に答える