3

REST API を公開する LAMP スタック Web アプリケーションがあります。目標は、データベース、サービス (REST)、および複数のフロントエンド クライアント (Web サイト、Android、iPhone) の 3 つの層を持つことです。現在、これらの層はすべて同じボックスにあります。Web サイトは API を使用して、CRUD 操作のサービス ロジックを呼び出します。モバイル クライアントはまだ構築されていません。

ユーザー資格情報を保存するために、PHP bcrypt 実装を使用しています。これは設計上、遅く、CPU を集中的に使用します。すべての API 呼び出しは、API パラメーターとともにユーザー名とパスワードのペアを受け取ります。これは、すべての API 呼び出しでハッシュが計算されるため、大規模なスケーリングを妨げます。

だから、私は代替案を探してきました。OAuth 2.0 は、使用するのに費用がかからない取り消し可能なトークンを使用しますが、私が読んだ記事では、このプロトコルの主な使用例は、サードパーティが API にアクセスできるようにすることであると示唆しているようです。たとえば、モバイルクライアントは私が所有しているため、これは私のモデルには完全には適合しません。

  1. OAuth はサードパーティでのみ使用することを意図したものですか? それとも、企業が独自の API の OAuth コンシューマとしてモバイル クライアントを追加するのが一般的ですか?

  2. アプリ マーケットに公開する Android/iPhone アプリに共有シークレットをバンドルして、すぐに API に関連付けることができますか?

4

1 に答える 1

3

oAuth v2 ( http://oauth.net/2/ ) には多数の認証パターン (全部で 6 つ) があり、エンド ユーザーがサード パーティのアプリを承認する「3 本足」のシナリオが最も目に付きますが、それでも間違いなく優れたアプローチです。アプリを所有している場合。

信頼できる資格情報フローhttps://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-25#section-4.3のような 2 つのレッグ フローを潜在的に使用できます。基本的に、これでは、ユーザーのユーザー名とパスワードを受信して​​表示し、API に送信するクライアント コード (作成したもの) を信頼します。これが完了すると、oAuth トークンが通常どおり発行され、パスワードが再度接続を通過する必要がなくなります。

共有シークレットに関する 2 番目の質問 - アプリが常にユーザー ログインを必要とする場合、認証はユーザーの資格情報に依存しているため、アプリに共有シークレットを配置することを回避できる可能性があります (この場合は、アプリに ID を配置するだけで、バージョンがわかります）。アプリが一部のモードでユーザーのログインなしで動作する場合、少なくとも init-step にはある種のシークレットを埋め込む以外に選択肢がほとんどない可能性があります。

于 2012-04-25T06:38:42.373 に答える