32

新しい OAuth2.0 仕様 (rfc 6749) を見ると、Implicit Grant プロトコル ワークフローが Url Hash Fragments を使用して、認可サーバーとパブリック クライアントの間で「access_token」を交換していることがわかります。

仕様を参照してください: https://www.rfc-editor.org/rfc/rfc6749#section-4.2

フローの他の部分をそのままにして、承認付与応答を Url フラグメントの代わりに「Query Params」として送信することはできませんか?

基本的に、OAuth2 の仕様作成者が Implicit grant flow authorization の URL ハッシュ フラグメントを選択した制限を理解できませんか?

4

2 に答える 2

25

Implicit Grant フローは Java スクリプト クライアントに対して行われ、「?」の代わりに「#」を使用していると思われます。リダイレクト URL のサーバー側にアクセス トークンを送信しないようにしますが、この場合はクライアントである JavaScript に到達しますが、これはセキュリティ上の理由による可能性があります。

于 2013-05-25T08:32:17.760 に答える
10

私の2セントを追加..

セキュリティの観点から、クエリ パラメータの代わりに URI フラグメントが使用されます。URI セグメントがネットワーク経由でリダイレクト URL に送信されることはありません。たとえば、Oauth 認証サーバーにログインした後、ロケーション ヘッダーには「ur redirect url」#access_token=uraccesstoken が含まれ、応答コードは 302 になります。ブラウザーが 302 を確認すると、ロケーション ヘッダー値に自動的にリダイレクトされます (ユーザーエージェントは自動的にそれを行い、javascriptはこれを止めることができません(afaik))。

これは URI フラグメントであるため、リダイレクト URL のみがネットワーク経由で送信され、uri フラグメントは送信されません。

クエリ パラメータの場合、クエリ パラメータもネットワーク経由で送信されます。TLS を使用しても、プロキシ ログにクエリ パラメータが表示されるため、アクセス トークンが意図しない人に知られてしまい、アクセス トークンが漏洩する可能性があります。

于 2016-12-06T16:08:40.680 に答える