0

私は、RESTful ハイパーメディア ベースの API のクライアントを構築しようとしています。多くのオプションを検討した後、oAuth* を学習して、API へのアクセスを承認するための事実上の方法になりました。

私は全体的な oauth の概念を理解していると思います。つまり、クライアント (信頼されているかどうか) に応じて、仕様は、リソース所有者 (ユーザー) へのアクセスを許可する観点からクライアント (アプリケーション) を「信頼」するためにいくつかのフローを提供します。クライアント。

私が構築しているアプリケーションは、サービスのエコシステムの直接の一部であるため、信頼できるクライアント セクションの傘下にあるため、リソース オーナーのパスワードの資格情報グラントを実装することにしましたが、ここで私の知識が混乱してしまいます。用語とoAuthが提供する正確な役割があり、私の脳は遮断されます:)

私はこれが流れだと思っています(さらに技術的な考えがあります):

  1. ログインフォームを介して、リソース所有者は資格情報を提供します
  2. 詳細はサーバー (この場合は express.js アプリ) に渡されます。
  3. アプリは、いくつかのローカル メカニズムを介してストアに対してユーザーの資格情報を認証します。
  4. ユーザーが存在しないか検証に失敗した場合、ログインに戻されます
  5. ユーザーが存在し、検証に合格した場合、暗号化/ハッシュ化された情報をどこかに保存するトークンの資格情報を交換するメカニズムが開始されます (oAuth サーバーに接続して詳細を交換します) (おそらく redis?)
  6. トークンが返されると、クライアントへの永続化のためにセッションに保存される可能性があります(trello.comはトークンCookieを持っているため、同様のことをしていると思いますが、ここでは非常に間違っている可能性があります)

これは許容できる流れですか?私は利用可能な例を見つけることができないようです.現在、唯一の開発者として、いくつかのフィードバックを得ることができます.

4

1 に答える 1

0

最終的に独自のフローを定義する必要はありません。これは単に、ユーザーの資格情報を信頼できるクライアントの oAuth トークンと交換したリソース オーナー パスワード グラントです。

于 2013-05-20T17:29:54.983 に答える