新しいOAuth2.0仕様（rfc 6749）を参照すると、暗黙の許可プロトコルワークフローでは、URLハッシュフラグメントを使用して、認可サーバーと公開クライアントの間で 'access_token'を交換しています。OAuth2.0暗黙のグラントフロー。なぜ、urlハッシュフラグメントを使用するのですか？
参照仕様は：http://tools.ietf.org/html/rfc6749#section-4.2
認証許可応答がそのまま流れの他の部分を保ち、「クエリーパラメータ」の代わりのURLがフラグメントとして送信することができませんか？
OAuth2の仕様作成者が暗黙的な許可フロー許可のためにurlハッシュフラグメントを選択したという制限は、基本的にわかりません。
Javaスクリプトクライアントでは暗黙的な許可フローが行われていますが、「？」ではなく「＃」が使用されていると思います。あなたのリダイレクトURLのサーバー側にアクセストークンを送信しないでくださいが、私たちのケースではクライアントであるjavascriptにはまだ届いていますセキュリティ上の理由から "ネットワーク経由でアクセストークンを共有していないと、私の2セントを追加
..
URIフラグメント
は、セキュリティの観点から、代わりにクエリパラメータを使用しています。 URIセグメントは、ネットワーク経由でリダイレクトURLに送信されることはありません。例えば、 Oauth Authorizationサーバにログインした後、ロケーションヘッダーには "ur redirect url"＃access_token = uraccesstokenがあり、レスポンスコードは302になります。ブラウザが302を見ると、自動的にロケーションヘッダ値にリダイレクトされます（ユーザエージェントそれを自動的に行い、javascriptはこれを止めることができません（afaik））。URIフラグメントであるため、リダイレクトURLだけがネットワーク経由で送信されるため、URIフラグメントは送信されません。
クエリパラメータの場合は、クエリパラメータもネットワーク経由で送信されます。 TLSを使用しても、クエリパラメータがプロキシログに表示され、アクセストークンが意図しないユーザーに知られてアクセストークンが漏洩する可能性があります。
ありがとうBobo！説明に同意します。リダイレクトへのリダイレクトがTLSを伴わないという仕様を読んでいると、トークンは「中間の攻撃者」の影響を受けやすくなります – aknon
しかしこれは認証コード付与フローに関する1つの質問をもたらします。このフローは、認証が成功した場合にAuthサーバーに「コード」を発行し、ユーザーエージェントをコードとともにredirect_urlにリダイレクトするように要求します。このリダイレクトにはTLSは関係しないため、認証コードのセキュリティが侵害されているわけではありませんか？ – aknon
コードはトークンを生成するために一度だけ使用され、クライアントIDとクライアントパスワードが必要です。クライアントのパスワードがクライアントシステムが知っているだけで共有されないように保護されます。 –