1

独自の REST アプリを構築したいと考えています。

主な認証アプローチとして oAuth を使用する予定です。

質問は: login と password を client_id と client_secret として (oAuth 仕様に関して) 使用できますか?

ユーザーを認証するサード サイドのアプリケーション、企業、サイトなどはありません。

私は独自の REST サーバーと JS アプリケーションを持っています。

サイト全体は通常の(RPC)アプローチで作成されますが、一部の非公開部分は、十分なスタンドアロンの JS アプリケーションを使用して RESTfull サービスとして実行されます。

更新: 完全な oAuth サポートが必要かどうかさえわかりません。httpsページでログインとパスワードを尋ねてから、トークンを生成できるようです。後で、このユーザーがすでに認証されているかどうかを確認するために使用できます。ただし、この場合、この oAuth は、Web アプリケーションにあるものとほぼ同じになります。ユーザーを認証するのに oAuth は必要ありませんか?

サーバーに毎回のユーザーとパスワードを送信したくないため、HTTP(s)認証は考慮していません。

4

3 に答える 3

0

アプリケーションをSLIに登録します。SLIは、アプリケーションがSLIAPIに対して認証できるようにする一意のクライアントIDとクライアントシークレットを付与します。また、認証および承認フローで使用するために、アプリケーションのリダイレクトURIを登録する必要があります。

特定の教育機関で申請書を有効にして、それらの地区での使用が承認されるようにします。

セッションと承認タイムアウトの管理を含む、アプリケーションで適切なOAuth2.0認証と承認フローを構成および実装します。

于 2012-06-04T05:19:57.460 に答える
0

いいえ。

OAuth が存在する主な理由の 1 つは、ユーザーがユーザー名とパスワードを侵害することなく統合できるようにすることです。

ユーザー名とパスワードを使用する予定がある場合、リクエストに署名したい場合はオプションとして xAuth を検討してください。詳細: https://dev.twitter.com/docs/oauth/xauth .

しかし、HTTP 基本認証を使用することもできます。少なくとも、SSL 経由で API を公開する場合。詳細: http://en.wikipedia.org/w/index.php?title=Basic_access_authentication

于 2012-05-25T14:13:04.407 に答える
0

セキュリティ サイトでより良い回答が得られると思います。たとえば、この質問を参照してください。

いずれにせよ、防御しようとしている攻撃と「許容できる」攻撃を詳細に評価することから始める必要があります。たとえば、HTTPS を使用している場合、SSL 証明書を偽造する必要があるため、中間者攻撃の残りの危険を受け入れることができます。一般に、リプレイ攻撃が許容されるかどうかを判断するのは困難です。

合理的な解決策の 1 つは、HTTPS でユーザー名とパスワードを使用してユーザーを認証し、有効期限のある安全なトークンを生成し、そのトークンと有効期限をクライアントに送信することで、期限付きの一時トークンを作成することです。たとえば、シークレットの SHA1 ハッシュとユーザー名と有効期限のタイムスタンプを取得することで、(合理的に) 安全なトークンを作成できます。その後、クライアントはトークン、ユーザー名、および認証タイムスタンプを将来のリクエストに含めることができ、シークレットと時計を使用してそれを検証できます。これらは 3 つのパラメーターとして送信する必要はありません。これらは 1 つの文字列に連結できますuser|timestamp|token。

于 2012-06-01T22:02:27.720 に答える