4

(ドラフト) 仕様を正しく理解していることを確認したいと思います。


[RFC3986] セクション 4.3で定義されているように、リダイレクト エンドポイント URI は絶対 URI でなければなりません。エンドポイント URI には、
"application/x-www-form-urlencoded" 形式
([W3C.REC-html401-19991224]) のクエリ コンポーネント ([RFC3986] セクション 3.4) を含めることができ、追加のクエリ パラメータを追加するときに保持する必要があります。エンドポイント URI にフラグメント コンポーネントを含めては
なりません。

私が質問する理由は、Google も Facebook もクエリ文字列を保持していないように見えるからです。

4

1 に答える 1

6

仕様を読み直すと、仕様の引用されたセクションは、OAuth サーバーの URI の処理ではなく、OAuth クライアントが指定された元のエンドポイント URI の処理に適用されるようです。

つまり、OAuth 認証のためにサーバーにリダイレクトするときに使用する必要がある OAuth エンドポイントは次のとおりです。

http://example.com/oauth.php?endpoint=token

次に、クライアントが を?response_type=code&client_id=...&state=...&redirect_uri=...URI に追加する場合、元のエンドポイント URI の「?endpoint=token」を破棄することは許可されず、URI を使用する必要があります。

http://example.com/oauth.php?endpoint=token&response_type=code&client_id=...&state=...&redirect_uri=...

したがって、少なくとも仕様のその部分に関する限り、Facebook、Google などは「状態」以外の不明なクエリ引数を保持する必要があるとは何も述べていません。

&state=技術的には、パラメーターを使用して、たとえば JSON 形式でカスタム データを渡すことができる場合があります。それはうまくいくかもしれないし、うまくいかないかもしれませんが。IIRC 特殊文字を使用すると、Meetup の OAuth 2 の実装が状態を台無しにするように見えることに気付きました。私が信じていることは、仕様に反しています。

于 2012-07-14T02:29:11.397 に答える