192

概要

アプリケーション用の (REST) API を作成しようとしています。初期/主な目的は、モバイル アプリ (iPhone、Android、Symbian など) での使用です。私は、Web ベースの API の認証と認可のさまざまなメカニズムを (他の実装を研究することによって) 調べてきました。基本的な概念のほとんどについて頭を悩ませていますが、まだいくつかの分野でガイダンスを探しています。私が最後にやりたいことは車輪の再発明ですが、私の基準に合った標準的な解決策が見つかりません (ただし、私の基準は見当違いである可能性があるので、それについても自由に批判してください)。さらに、API を使用するすべてのプラットフォーム/アプリケーションで同じ API を使用したいと考えています。

oAuth

oAuth が提供される最初のソリューションになる可能性が高いことはわかっているので、oAuth に異議を唱えます。モバイル アプリケーション (より具体的には非 Web アプリケーション) の場合、認証のためにアプリケーションを離れる (Web ブラウザーに移動する) のは間違っているようです。さらに、ブラウザーがコールバックをアプリケーション (特にクロスプラットフォーム) に返す方法はありません (私は認識しています)。私はそれを行うアプリをいくつか知っていますが、それは単に間違っていると感じ、アプリケーションの UX を中断させてしまいます。

要件

  1. ユーザーはユーザー名/パスワードをアプリケーションに入力します。
  2. すべての API 呼び出しは、呼び出し元のアプリケーションによって識別されます。
  3. オーバーヘッドは最小限に抑えられ、認証の側面は開発者にとって直感的です。
  4. このメカニズムは、エンド ユーザー (ログイン資格情報が公開されない) と開発者 (アプリケーション資格情報が公開されない) の両方にとって安全です。
  5. 可能であれば、https を要求しないでください (決して厳しい要件ではありません)。

実装に関する私の現在の考え

外部の開発者が API アカウントを要求します。apikey と apisecret を受け取ります。すべてのリクエストには、少なくとも 3 つのパラメータが必要です。

  • apikey - 登録時に開発者に与えられる
  • タイムスタンプ - 特定の apikey の各メッセージの一意の識別子としても機能します
  • hash - タイムスタンプ + apisecret のハッシュ

apikey は、リクエストを発行するアプリケーションを識別するために必要です。タイムスタンプは oauth_nonce と同様に機能し、リプレイ攻撃を回避/軽減します。ハッシュは、リクエストが実際に特定の apikey の所有者から発行されたことを保証します。

認証済みのリクエスト (ユーザーに代わって行われるリクエスト) については、access_token ルートを使用するか、ユーザー名とパスワードのハッシュの組み合わせを使用するか、まだ決めかねています。いずれにせよ、ある時点でユーザー名とパスワードの組み合わせが必要になります。その場合、いくつかの情報 (apikey、apisecret、timestamp) + パスワードのハッシュが使用されます。 この点についてフィードバックをいただければ幸いです。 参考までに、パスワードをハッシュせずにシステムに保存しないため、最初にパスワードをハッシュする必要があります。

結論

参考までに、これは API を構築/構造化する方法の要求ではなく、アプリケーション内のみから認証と承認を処理する方法のみです。

ランダムな考え/ボーナス質問

リクエストの一部として apikey のみを必要とする API の場合、apikey の所有者以外の誰かが apikey を (平文で送信されているため) 見ることができず、使用制限を超えてそれらをプッシュする過度のリクエストを行うことをどのように防ぎますか? たぶん私はこれを考えすぎているだけかもしれませんが、リクエストが apikey 所有者に対して検証されたことを認証するものがあるべきではありませんか? 私の場合、それが apisecret の目的であり、ハッシュされずに表示/送信されることはありません。

ハッシュといえば、md5 と hmac-sha1 はどうですか? すべての値が十分に長いデータ (つまり、apisecret) でハッシュされている場合、それは本当に重要ですか?

以前、ユーザーのパスワード ハッシュにユーザー/行ごとのソルトを追加することを検討していました。私がそれを行うとしたら、使用されているソルトを知らずに、アプリケーションはどのようにして一致するハッシュを作成できるのでしょうか?

4

5 に答える 5

45

私のプロジェクトでこれのログイン部分を行うことについて私が考えている方法は次のとおりです。

  1. ログインする前に、ユーザーlogin_tokenはサーバーに a を要求します。これらは要求に応じて生成され、サーバーに保存され、おそらく有効期間が限られています。

  2. アプリケーションにログインするには、ユーザーのパスワードのハッシュを計算し、パスワードを でハッシュして値を取得し、 と組み合わせたハッシュのlogin_token両方を返します。login_token

  3. サーバーは、login_tokenが生成したものであることを確認し、有効な のリストから削除しますlogin_token。次にサーバーは、保存されているユーザーのパスワードのハッシュを と結合しlogin_token、送信された結合トークンと一致することを確認します。一致する場合は、ユーザーが認証されています。

これの利点は、ユーザーのパスワードをサーバーに保存しないこと、パスワードが平文で渡されることがないこと、パスワード ハッシュがアカウントの作成時に平文でのみ渡されることです (ただし、これを回避する方法はあります)。login_tokenは使用時に DB から削除されるため、リプレイ攻撃から安全です。

于 2010-10-19T05:59:48.823 に答える
14

たくさんの質問がありますが、かなりの数の人が最後まで読むことができなかったと思います:)

Web サービス認証に関する私の経験では、人々は通常それを過剰に設計しており、問題は Web ページで遭遇するものと同じです。考えられる非常に単純なオプションとして、ログイン ステップに https を含め、トークンを返し、将来のリクエストにトークンを含める必要があります。http 基本認証を使用して、ヘッダーに何かを渡すこともできます。セキュリティを強化するには、トークンを頻繁にローテーション/期限切れにし、リクエストが同じ IP ブロックから送信されていることを確認し (モバイル ユーザーがセル間を移動すると混乱する可能性があります)、API キーなどと組み合わせます。または、ユーザーを認証する前に oauth の「キーのリクエスト」ステップを実行し (誰かが以前の回答でこれを提案しましたが、それは良い考えです)、それを必要なキーとして使用してアクセストークンを生成します。

まだ使用していませんが、デバイスに適した oAuth の代替手段としてよく耳にするのはxAuthです。実際に見て、使ってみて感想を聞かせてください。

ハッシュについては、sha1 の方が少し優れていますが、それにこだわらないでください。デバイスが簡単に (そしてパフォーマンスの点で迅速に) 実装できるものであれば、おそらく問題ありません。

お役に立てば幸いです、頑張ってください:)

于 2010-10-29T08:20:35.863 に答える
9

では、モバイル アプリケーションの認証と承認の側面を処理する、ある種のサーバー側認証メカニズムを求めているのでしょうか。

これが事実であると仮定すると、次のようにアプローチします (ただし、私は Java 開発者であるため、C# 担当者は別の方法で行うことになります)。

RESTful 認証および認可サービス

  1. これは、盗聴を防ぐために HTTPS 経由でのみ機能します。
  2. これは、 RESTEasy、Spring Security、およびCAS (複数のアプリケーションにわたるシングル サインオン用)の組み合わせに基づいています。
  3. ブラウザーと Web 対応のクライアント アプリケーションの両方で動作します。
  4. ユーザーが自分の詳細を編集できるようにする Web ベースのアカウント管理インターフェイスと、管理者 (特定のアプリケーション用) が承認レベルを変更できるようになります。

クライアント側のセキュリティ ライブラリ/アプリケーション

  1. サポートされているプラ​​ットフォーム (例: Symbian、Android、iOS など) ごとに、プラットフォームのネイティブ言語 (例: Java、ObjectiveC、C など) でセキュリティ ライブラリの適切な実装を作成します。
  2. ライブラリは、特定のプラットフォームで利用可能な API を使用して HTTPS リクエストの形成を管理する必要があります (たとえば、Java は URLConnection などを使用します)。
  3. 一般的な認証および承認ライブラリ (これだけです) の利用者は、特定のインターフェイスに合わせてコーディングし、それが変更されても満足しないので、非常に柔軟であることを確認してください。Spring Security などの既存の設計の選択肢に従います。

では、高度 30,000 フィートからのビューは完成しましたが、どのように行うのでしょうか。一覧にあるテクノロジに基づいて、ブラウザー クライアントを使用してサーバー側で認証および承認システムを作成することはそれほど難しくありません。フレームワークは、HTTPS と組み合わせて、認証プロセスによって生成され、ユーザーが何かをしたいときにいつでも使用される共有トークン (通常は Cookie として提示される) に基づく安全なプロセスを提供します。このトークンは、リクエストが発生するたびにクライアントからサーバーに提示されます。

ローカル モバイル アプリケーションの場合、次のことを行うソリューションを求めているようです。

  1. クライアント アプリケーションには、メソッド呼び出しへのランタイム アクセスを制御する定義済みのアクセス制御リスト (ACL) があります。たとえば、特定のユーザーはメソッドからコレクションを読み取ることができますが、ACL は名前に Q が含まれるオブジェクトへのアクセスのみを許可するため、コレクション内の一部のデータはセキュリティ インターセプターによって静かにプルされます。Java ではこれは簡単です。呼び出し元のコードで Spring Security アノテーションを使用し、適切な ACL 応答プロセスを実装するだけです。他の言語では、独自のセキュリティ ライブラリを呼び出すボイラープレート セキュリティ コードを提供する必要があります。言語が AOP (アスペクト指向プログラミング) をサポートしている場合は、この状況で最大限に使用してください。
  2. セキュリティ ライブラリは、承認の完全なリストを現在のアプリケーションのプライベート メモリにキャッシュするため、接続したままにする必要はありません。ログイン セッションの長さによっては、これは繰り返されることのない 1 回限りの操作になる可能性があります。

何をするにしても、独自のセキュリティ プロトコルを発明しようとしたり、あいまいな方法でセキュリティを使用したりしないでください。現在利用可能で無料のアルゴリズムよりも優れたアルゴリズムを作成することはできません。また、人々はよく知られたアルゴリズムを信頼しています。したがって、SSL、HTTPS、SpringSecurity、および AES 暗号化トークンの組み合わせを使用して、セキュリティ ライブラリがローカル モバイル アプリケーションの認可と認証を提供するとすれば、すぐに市場で信用を得ることになります。

これがお役に立てば幸いです。あなたの冒険に幸運を祈ります。詳細が必要な場合はお知らせください。Spring Security、ACL などに基づいてかなりの数の Web アプリケーションを作成しました。

于 2010-10-28T12:36:49.160 に答える
9

Twitter は、 xAuthと呼ばれるバリアントをサポートすることで、oAuth の外部アプリケーションの問題に対処しました。残念ながら、この名前のスキームはすでに他にもたくさんあるため、整理するのが混乱する可能性があります。

プロトコルはoAuth ですが、リクエスト トークン フェーズをスキップし、ユーザー名とパスワードを受け取るとすぐにアクセス トークン ペアを発行します。(ここのステップ Eから開始します。) この最初の要求と応答は保護する必要があります。- ユーザー名とパスワードをプレーンテキストで送信し、アクセス トークンとシークレット トークンを受け取ります。アクセス トークン ペアが構成されると、最初のトークン交換が oAuth モデルを介して行われたか xAuth モデルを介して行われたかは、残りのセッションではクライアントとサーバーの両方に関係ありません。これには、既存の oAuth インフラストラクチャを活用できるという利点があり、モバイル/Web/デスクトップ アプリケーションに対してほぼ同じ実装を行うことができます。主な欠点は、アプリケーションがクライアントのユーザー名とパスワードへのアクセスを許可されていることですが、要件ではこのアプローチが義務付けられているようです。

いずれにせよ、私はあなたの直感とここにいる他の何人かの回答者の直感に同意したいと思います.ゼロから何か新しいものを構築しようとしないでください. セキュリティ プロトコルは簡単に始めることができますが、うまく実行するのは常に難しく、複雑になればなるほど、サードパーティの開発者がそれらに対して実装できる可能性は低くなります。架空のプロトコルは o(x)Auth と非常によく似ています - api_key/api_secret、nonce、sha1 ハッシュ - しかし、多くの既存のライブラリの 1 つを使用できる代わりに、開発者は独自のものを作成する必要があります。

于 2010-10-29T08:54:06.683 に答える