Должны ли динамические параметры запроса присутствовать в URI перенаправления для OAuth2 (тип предоставления кода авторизации)

Question

В таких источниках, как этот Сайт, спонсируемый Okta (см. Раздел «Настройка по запросу»), упоминается, что параметр redirect_uri запроса на авторизацию НЕ ДОЛЖЕН иметь динамическую часть запроса (например, для использования при сопоставлении сеансов) .

Цитата:

Сервер должен отклонять любые запросы авторизации с URL перенаправления. которые не являются точным соответствием зарегистрированного URL.

Наш поставщик услуг OAuth AZ BIG-IP F5. Мы его настраиваем, и они, похоже, соответствуют приведенному выше мнению.

Наш клиент - это веб-приложение, созданное в другом месте, и они, похоже, не следуют вышеуказанному правилу Вот полное представление конечной точки авторизации (отредактировано): https://ourownF5host.ca/f5-oauth2/v1/authorize?client_id=theIDofOurClient&redirect_uri=https%3A%2F%2FourClientAppHostname%2FClientRessource%2FRessource%3FSessionId%3D76eab448-52d1-4adb-8eba-e9ec1b9432a3&state=2HY-MLB0ST34wQUPCyHM-A&scope=RessourceData&response_type=code

Они используют redirect_uri с форматом, похожим на (для простоты я не буду здесь код urlencode): redirect_uri = https://ourClientAppHostname/ClientRessource/Ressource?SessionId=SOMELONGSESSIONID, со значением SOMELONGSESSIONID, РАЗЛИЧНЫМ для каждого вызова.

Мы выкопали DEEP в RFC6749 (OAuth2) и обнаружили это в разделе 3.1.2.2:

.

Сервер авторизации ДОЛЖЕН требовать от клиента предоставления
полный URI перенаправления (клиент МОЖЕТ использовать запрос «state»
параметр для достижения индивидуальной настройки). Если требуется
регистрация полного URI перенаправления невозможна,
серверу авторизации СЛЕДУЕТ требовать регистрации URI
схема, полномочия и путь (позволяющие клиенту динамически изменяться
только компонент запроса URI перенаправления при запросе
авторизация).

Что я понимаю и хотел бы проверить здесь, так это то, что первый источник Okta и F5 принимают ТОЛЬКО первую часть вышеприведенного правила и требуют, чтобы URI перенаправления был полностью зарегистрирован без какой-либо динамической части.

Правильно ли я подтвердить, что они (Okta и F5) НЕ соответствуют второй части отрывка, сославшись на то, что они должны " разрешать (изменять) клиенту динамическое изменение только компонент запроса URI перенаправления при запросе авторизация"?

ИЛИ, существует ли какое-либо официальное исправление / развитие RFC6749, которое оправдывает позицию обеих компаний?

Answer 1

TL; DR :

Нет, URI перенаправления должен быть статическим по соображениям безопасности.Если клиенту необходимо сохранить state между запросом авторизации и его асинхронным ответом, используйте параметр OAuth 2.0 state.

Длинная версия :

RFC6749(первоначальная спецификация OAuth 2.0) была опубликована в 2012 году, и с тех пор ситуация с безопасностью OAuth сильно изменилась.

RFC6819, обзор безопасности OAuth 2.0 от 2013 года уже упоминал, что отказ от динамически созданного перенаправления Uris является хорошим способом защиты от атак с использованием имитации XSS и клиентов.

OpenID Connect , начиная с 2014 года, широко используемое расширение OAuth 2.0 с возможностями аутентификации, уже учитывает эту рекомендацию и предписывает точное сопоставление строк для всех адресов перенаправления.

Текущий проект рекомендациидля OAuth 2.0 Best Security Practice подтверждает это путем принудительной предварительной регистрации redirect_uris и предписания AS использовать простое сравнение строк при проверке redirect_uri, переданного в запросе.Таким образом, динамическое redirect_uri не должно использоваться.

Ваш клиент определенно делает неправильный шаг, используя redirect_uri в качестве «хранителя состояний» между запросом авторизации и ответом, используя динамически созданный атрибут SessionID внутриredirect_uri.Для этой цели OAuth2.0 имеет выделенный параметр запроса авторизации, который является " state ".Клиент должен использовать это.AS добавит это состояние в параметры redirect_uri при выдаче ответа, поэтому клиент сможет найти это состояние внутри ответа.

Правильный запрос авторизации будет выглядеть так:

https://youras/authorize?client_id=your_client_id&response_type=code&state=SOMELONGSTATE&redirect_uri=https%3A%2F%2Fsomehost%2Fauthcallback

Ответ будет выглядеть следующим образом: https://somehost/authcallback?state=SOMELONGSTATE&code=anazcode

Таким образом, redirect_uri является статическим, поэтому простого сравнения строк достаточно для проверки тогона стороне AS.Любой алгоритм, более сложный, чем простое сравнение строк, будет подвержен недостаткам безопасности.

Answer 2

Похоже, здесь есть две вещи: URL, на который вы ссылаетесь:

 https://somehost/authcallback?state=SOMELONGSTATE&scope=someobjecttype&response_type=code

предполагает, что вы перепутали URI перенаправления (или URL-адрес обратного вызова, как указано в URL-адресе пути) клиента с конечной точкой авторизации сервера авторизации.

Только конечная точка авторизации может принимать параметры в соответствии с предложением и может содержать, например, динамическое значение state. URI перенаправления клиента не будет содержать, например, тип ответа.

Параметр redirect_uri может быть добавлен к запросу на авторизацию, который затем должен соответствовать описанному вами. После подтверждения соответствия сервер авторизации перенаправит обратно на URI перенаправления, добавив параметры code и state.

Обновление (после изменения вопроса):

OAuth 2.0 RFC6749 допускает динамический (SessionId) параметр, хотя это не считается наилучшей практикой. Однако если ваш клиент является клиентом OpenID Connect, это не разрешено, поскольку спецификация OpenID Connect («профиль» OAuth 2.0) блокирует URI перенаправления, совпадающий с «точным», и в этом случае вам придется настроить все возможные SessionIds.