0
この質問はアーキテクチャーの問題によく似ています。私は次の設定が意味を成すのだろうかと思います。リソース所有者グラントフローのIdentity Serverユースケース
- クライアント：ユーザーのブラウザ
- Webサーバー：WebアプリケーションのためのWeb APIを提供し、サーバー。クライアントは、Webサーバーへのログインのための要求を送信すると
- のIdentity Server
は、Webサーバーは要求を受信し、アクセストークンを取得するには、リソースの所有者グラント・タイプでアイデンティティサーバーに送信します。
クライアントがリソースの要求を送信すると、前の手順のアクセストークンを使用してWebサーバーにアクセスし、Webサーバーはリソースを提供する前に毎回Identityサーバーで要求を確認する必要があります。
はしかし、私はクライアントもSSL接続の下で信頼クライアントがある場合は、このアーキテクチャでは、Webサーバが確認することはできません
のようないくつかの問題を抱えているかもしれないと思います。クライアントは常にアクセストークンを取得し、Webサーバーに要求を送信できます。しかし、私はこの問題が他の助成金タイプにも存在するように感じます。 私は、ユーザーが許可スコープを変更できない、または他の誰かが（SSL接続の下で）トークンを傍受している限り、それは問題ないはずだと思います。
ありがとう！
まあが、私の質問は、より多くのWebサーバーとIDSrvは同じ党からの両方であるときのように、3本足の認証の代わりに、2を実行する利点は何です-legged？ – maxisam
ブラウザフローなしで複数のアプリケーション間でSSOを取得することはありません。 – leastprivilege
良い点。だから私はそれを作るようにユーザーがWeb srvにユーザー名/パスワードを送信し、Web srvがIDSrvにそれを送信してアクセストークン（リソース所有者フロー）を取得します。 Web srvが取得すると、それをUserに送り返します。それでもSSOがあり、ユーザーはIDSrvと直接リソース所有者のフローで対話しません。それは動作しますか？他のフローにはURIリダイレクトが必要であるため、既存のネイティブアプリを操作するのには理想的ではありません。 – maxisam