OAuth2.0 Неявный поток грантов. Зачем использовать хэш-фрагменты URL?

Просматривая новые OAuth2.0 Specs (rfc 6749), я вижу, что рабочий процесс протокола Implicit Grant использует фрагменты Url Hash для обмена "access_token" между сервером авторизации и публичным клиентом.

См. характеристики: http://tools.ietf.org/html/rfc6749#section-4.2

Невозможно ли отправить ответ разрешения авторизации как "Параметр запроса" вместо фрагмента Url, сохраняя другие части потока как есть?

В принципе, я не могу понять ограничения, которые заставили авторов spec-ов OAuth2 выбрать фрагменты хеша URL-адресов для авторизации потока неявного разрешения?

Ответ 1

поток Implicit Grant выполняется для java script клиентов, и я думаю, что они используют '#' вместо '?' чтобы не отправлять маркер доступа на серверную сторону URL-адреса переадресации, но он по-прежнему доходит до javascript, который является клиентом в нашем случае, может быть по соображениям безопасности, "не разделяя токен доступа через сеть, может быть необеспеченным, как тот, который используется для URL-адреса переадресации"

Ответ 2

Добавление моих 2 центов.

Фрагмент URI используется вместо параметра запроса, с точки зрения безопасности. Сегмент URI никогда не будет отправлен по сети на URL-адрес перенаправления. Напр. после входа на сервер авторизации Oauth в заголовке местоположения будет "ur redirect url" # access_token = uraccesstoken, а код ответа будет равен 302. Когда браузер увидит 302, он автоматически перенаправит на значение заголовка местоположения (пользовательский агент делает это автоматически, и javascript не может остановить это (afaik)).

Поскольку он является фрагментом URI, только URL перенаправления отправляется по сети, фрагмент uri - нет.

Если это параметр запроса, параметр запроса также будет отправлен по сети. Даже с TLS параметр запроса будет отображаться в ваших журналах прокси, что делает наш токен доступа неизвестным людям, вызывая утечку токена доступа.