2

api.example.com の API バックエンドと example.com のフロントエンド シングル ページ アプリの両方を所有しています。API は基本的に、データベース バックエンドのラッパーです。

ここで、シングル ページ アプリ (= クライアント アプリ) のユーザーに API で認証してもらいたいと考えています。このために、私が理解している限り、クライアント (= シングル ページ アプリ) は client_id を user_id と共に API に送信し、API は AccessToken を発行します。

ただし、私の単一ページ アプリでは、アクセス トークンをどこにどのように保存するかがわかりません。ログインしたユーザーがAPIアプリケーションにアクセスできるようにするための簡単なリファレンス、または良いコンセプトを探しています。

友人が私にこのフローを提案しました：

  1. クライアントは、ログイン (電子メールまたはユーザー名) とパスワードの入力を表示します。
  2. クライアント アプリは API にリクエストを送信し、承認されていないトークンを取得します (例: POST /api/v1/auth/new)。
  3. サーバーはアプリのトークンを作成して送り返します。
  4. クライアント アプリは、トークンをログイン、パスワード、および要求署名と共に API に送信します (例: POST /api/v1/mobile_authenticate)。
  5. API は資格情報を検証および検証します。
  6. すべて問題なければ、アプリはトークンを使用して、ユーザーに代わってさらに処理を行います。

何かご意見は？これをどのように簡素化または改善できますか?

4

1 に答える 1

4

サーバー API のアクセス許可チェックに API キーを使用しています。API キーがどのように機能するかのワークフローは次のとおりです。

  1. クライアント アプリには、ログイン (電子メールまたはユーザー名) とパスワードの入力が表示されます。
  2. クライアント アプリは、API キーを取得するために API に要求を行います (例: POST /api/v1/users/validate)。
  3. クライアント アプリは、API キーを使用して API にアクセスします。(http リクエストの場合、API キーは http ヘッダーまたはクエリ文字列に含めることができます。)

それが役に立てば幸い。

于 2013-03-12T14:05:37.223 に答える