3

私はかなり初心者で、フローの一部 (またはどのベスト プラクティスを使用すべきか) を理解するのに苦労していますOAuth 2.0...OpenID Connect

長い投稿で申し訳ありません:)

私のセットアップ:

  1. ( OPOpenID プロバイダー) は、基本的にと を使用してユーザーを認証および承認するexpressサーバーです。呼びましょうoauth2orize-openidpassporthttp://authserver.com

  2. my に対してユーザーを認証する必要があるSingle page application(react+webpack) 、それをOP呼び出しましょうhttp://my-spa.com

これはSPA（webpackによって静的に提供される）なので、使用する必要がありますImplicit Flow。

私の質問

ユーザーが に移動すると、アプリケーションがロードされ、 が存在するかどうかhttp://my-spa.comがチェックされます。localStorageid_token

いいえid_tokenオンlocalStorageロード:

  1. トークンがないので、リダイレクトしますhttp://authserver.com/dialog/authorize
    • response_type=id_token
    • scope=openid profile
  2. ユーザーが正常に認証および承認されると、URI フラグメント内のにauthserverリダイレクトされますmy-spaid_token
  3. に保存するid_tokenとlocalStorage、ユーザーはアプリの使用を開始できます。

ロード中id_tokenですlocalStorage

ユーザーがブラウザを閉じて、再度開きました。これは、私が何をすべきかを理解するのに苦労しているところです。(以前のログインからの) トークンが既に存在するため、それが有効かどうかを確認する必要があります。

そのためのベストプラクティスは何ですか? これが私が正しいと思うものです：

  1. を使用するようにリダイレクトhttp://authserver.com/dialog/authorize:
    • prompt=none
    • id_token_hint=CURRENT_TOKEN
  2. OPこのリクエストを受信すると、JWT 署名を検証し、ユーザーの自動承認を試みて、新しい JWT でリダイレクトする必要があります。

しばらくするとトークンが期限切れになります

ログインしたユーザーの JWT が期限切れになったとしましょう。いつ新しいものを要求する必要がありますか? 更新のトリガーは何ですか？

/tokeninfoまたはは何の/userinfoためにありますか?

私の理解では、JWT はユーザーを識別するために必要なすべてのデータを保存します。/tokeninfoただし、 orを呼び出す例を見てきました/userinfo。

IDを既に持っている場合sub、これらのエンドポイントはトークンを検証するためだけのものですか (サブジェクトの ID 以外は何も必要ないと仮定します)?

JWT署名検証

のほかに、JWT 署名を検証するOP必要がありmy-spaますか (おそらく公開鍵を使用)?

このトークンを再利用して、3 番目のサービスの REST API にアクセスする

別の Web サービス API がhttp://my-service.com/apiあり、SPA から呼び出したユーザーを知る必要がある場合は、次の手順を実行する必要があります。

  1. をトークンとして各 ajax リクエストにid_token追加しますBearer
  2. my-service.comJWT署名を（公開鍵で？）検証し、保護されたリソースへのアクセスを許可するか拒否するかを決定する必要があります

どんな助けでも大歓迎です！

4

1 に答える 1

3

?あなたの質問は大きいです。私は一般的な方法で（あなたが使用している特定のフレームワークを考慮せずに）でマークされたすべてのフレーズに答えようとします.

ロード時に localStorage に id_token があります。

ユーザーがブラウザを閉じて、再度開きました。そのためのベストプラクティスは何ですか?

楽観的でトークンの使用を継続するか、悲観的で新しいトークンを要求するかを選択できます。

  • 有効期限が十分に長い場合は、引き続きトークンを使用してください。トークンは各リクエストで検証されると想定しているため、トークンが無効な場合は 401 を受け取り、新しいトークンをリクエストできます

  • 有効期限が短い場合、またはブラウザーがアプリケーションを開いたときに新しいユーザー認証を要求する場合は、新しいトークンを要求します。JWT がまだ有効かどうかを確認したい場合、認証サーバーを使用したリダイレクトは SPA にとってユーザーフレンドリーではありません。AJAX 呼び出しを実行して検証し、新しいトークンを要求することをお勧めします。

しばらくするとトークンが期限切れになります

これは、上で説明した最初のケ​​ースです。リクエストごとに、または一定期間、つまり1時間後に新しいトークンを発行しないようにすることができます

/tokeninfo または /userinfo は何のためのものですか?

私はこれらのサービスを知りませんが、その意味は推測できます。JWT は署名されているため、含まれているデータを信頼できます (署名が有効な間)。

JWT署名の検証、OPのほかに、my-spaはJWT署名を検証する必要がありますか(おそらく公開鍵を使用)?

リクエストごとに署名を検証する必要があります。対称鍵 (つまり HMAC) を使用する場合、JWT は同じ鍵で署名および検証されます。非対称鍵 (RSA) を使用すると、JWT は秘密鍵で署名され、公開鍵で検証されます

このトークンを再利用して、3 番目のサービスの REST API にアクセスする

各 ajax リクエストに id_token を Bearer トークンとして追加し、

正解、通常は Authorization ヘッダーを使用

my-service.com は JWT 署名を (公開鍵を使用して) 検証し、保護されたリソースへのアクセスを許可するか拒否するかを決定する必要があります。

もちろん、JWT を使用するサービスは署名を検証する必要があります。外部サービスは秘密鍵を所有していないため、この場合は非対称鍵を使用する必要があります。外部サービスがトークンを検証できるように、公開鍵を公開する必要があります

于 2017-01-06T22:04:52.633 に答える