Если «состояние» отправляет пользователя в другой домен (например, то же приложение в другом гео-регионе), то процесс повторяется (IP перенаправляет обратно в / oidc-signin этого гео-экземпляра), но пользователю не нужно снова предоставлять учетные данные (SSO ), но нужно дождаться завершения взаимодействия. Как я понимаю...

уURL перенаправления должны соответствовать полностью? Разве сопоставления на уровне домена не будет достаточно для надлежащей безопасности?

Что если бы у меня были сотни путей?

пример URL:

https://myawesomesite.comhttps://myawesomesite.com/account/profilehttps://myawesomesite.com/games/fungame/pointshttps://www.myawesomesite.com/games/fungame/points

...

Мне нужно будет ввести 4 вышеупомянутых URL-адреса перенаправления в конфигурацию моего приложения B2C.

 spottedmahn28 нояб. 2017 г., 04:46
Нет. Представьте, что у меня есть 100 уникальных путей, и 99 из них аутентифицированы. Пользователь может добавить в закладки любой из 99 путей.
 Chris Padgett28 нояб. 2017 г., 04:42
Ваше удивительное приложение обрабатывает все ответы аутентификации в одной и той же конечной точке (например, / oidc-signin)?
 spottedmahn28 нояб. 2017 г., 04:47
@ChrisPadgett, если они попадают на аутентифицированную страницу, он должен перенаправить на B2C и вернуться на эту страницу.

Ответы на вопрос(2)

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

Один (часто известный какURL ответа), который передается в параметре "redirect_uri", которыйдолжно быть зарегистрирован в Azure AD B2C, к которомувсе ответы проверки подлинности возвращаются из Azure AD B2C в приложение проверяющей стороны. Примером этого являетсяhttps://www.myawesomesite.com/oidc-signin.Другой (часто известный какобратный URL), который округляется в параметре "состояние", которыйне должно быть зарегистрирован в Azure AD B2C, к которому конечный пользователь возвращается после того, как приложение проверяющей стороны обработало ответ аутентификации. Примером этого являетсяhttps://www.myawesomesite.com/games/fungame/points.

Обработчик аутентификации, такой какпромежуточное ПО для аутентификации ASP.NET Core, управляет этими URL перенаправления для вас.

Например, когда обработчик аутентификации создает запрос аутентификации, он кодирует текущий защищенный URL (например,https://www.myawesomesite.com/games/fungame/points) в параметре запроса "state".

Чтобы этот URL-адрес не был изменен, параметр «состояние» должен быть защищен с использованием шифрования или подписи.

Когда обработчик аутентификации обрабатывает ответ аутентификации, предполагая, что это успешный ответ, он создает идентификационный файл cookie и перенаправляет конечного пользователя изhttps://www.myawesomesite.com/oidc-signin на первоначально защищенный URL в параметре ответа «состояние».

 GGleGrand21 янв. 2019 г., 12:16
Если «состояние» отправляет пользователя в другой домен (например, то же приложение в другом гео-регионе), то процесс повторяется (IP перенаправляет обратно в / oidc-signin этого гео-экземпляра), но пользователю не нужно снова предоставлять учетные данные (SSO ), но нужно дождаться завершения взаимодействия. Как я понимаю...
Решение Вопроса

RFC 6819 Разделы «Модель угроз OAuth 2.0 и соображения безопасности»4.1.5, 4.2.4 а также5.2.3.5.

4.1.5. Угроза: открыть редиректоры на клиенте

Открытый перенаправитель - это конечная точка, использующая параметр для автоматического перенаправления пользовательского агента в местоположение, указанное значением параметра, без какой-либо проверки. Если сервер авторизации позволяет клиенту регистрировать только часть URI перенаправления, злоумышленник может использовать открытый перенаправитель, управляемый клиентом, для создания URI перенаправления, который пройдет проверку сервера авторизации, но отправит «код» авторизации или токен доступа. до конечной точки под контролем атакующего.

Воздействие. Злоумышленник может получить доступ к «кодам» авторизации или токенам доступа.

Контрмеры:

o Требовать от клиентов регистрации полного URI перенаправления (Раздел 5.2.3.5) «.

Раздел 5.2.3.5 рассказывает о случаях, когда это может быть слишком ограничительным, и о целях альтернативных решений.

Часто временаstate Параметр также можно использовать для детерминированного перенаправления, как это было предложено Крисом.

 Omer Iqbal30 нояб. 2017 г., 07:41
Спасибо за редактирование моего ответа spottedmahn. Вчера вечером у меня была только мобильная страница, на которой не было полнофункционального редактора.
 spottedmahn30 нояб. 2017 г., 16:40
ах, "параметры запроса", хорошая мысль! спасибо за подробный ответ!
 spottedmahn29 нояб. 2017 г., 16:19
Если у меня есть домен myawesomesite.com, и у меня есть открытый перенаправитель, который позволяет любой URL-адрес перенаправления в этом домене, как может обезьяна злоумышленника с URI перенаправления? Это все равно придется перенаправить на мой домен.
 spottedmahn30 нояб. 2017 г., 16:45
дополнительный вопрос оиспользуя параметр состояния
 Omer Iqbal30 нояб. 2017 г., 07:40
Распространенный случай - когда redirect_url принимает некоторые параметры запроса, которые могут быть использованы злоумышленником для перенаправления на их сайт. Модель угрозы предполагает, что пользовательский агент перенаправляется «без какой-либо проверки». То, что вы предлагаете, это какие-то ограничения или проверки. Azure AD пытается найти баланс с помощью подхода, который работает в большинстве случаев, но по-прежнему ограничивает подстановочные знаки и параметры запроса. (Обратите внимание, что эти уязвимости все еще случаются сегодня, особенно в сложных приложениях:google.com/...)

Ваш ответ на вопрос