Как безопасно хранить ReturnUrl в IdentityServer4?
Я разрабатываю основное приложение dotnet для сервера идентификации 4, так что это больше вопрос dotnet, чем вопрос IDS4. Одним из примеров состояния, которое мне нужно поддерживать между страницами (вход в систему, регистрация и т. д.), является returnUrl. Приложение, из которого я мигрирую, использовалось для хранения его в переменной сеанса, но, как я понимаю, если я не использую стратегию постоянного сеанса, это не будет хорошо масштабироваться.
Итак, в настоящее время я передаю его как поле в каждой модели представления, используемой каждым представлением, чтобы его можно было вернуть. Это здравый подход? Мне понадобятся и другие поля, поэтому мне интересно, является ли это безопасным и логичным способом сделать это.
Наш процесс входа включает в себя ссылки на регистрацию и другие параметры входа, такие как внутренние входы, поэтому мне нужно обязательно передать returnURL и на эти страницы. Таким образом, проблема заключается в том, что пользователь может перемещаться между этими страницами по-разному.
Поделитесь с нами, что вы пробовали и где это не сработало. Что такое internal logins? Есть ли у вас проблемы с перенаправлением при регистрации или внутреннем входе в систему?
Ответы 1
So currently, I'm passing it around as a field in each View Model used by each view so it can be returned. Is this a sound approach?
Да, как вы решите передать это, зависит от вас, я выбираю тот же подход. В качестве альтернативы вы можете использовать TempData, Sessions или даже localStorage. Я думаю, что наличие его в моделях (моделях просмотра) - это хороший подход, потому что вы явно указываете, где вы хотите, чтобы возвращаемый URL-адрес существовал, иначе он может сохраняться в контексте, который вам не нужен.
Теперь контрольный вопрос, потому что, очевидно, вы сможете увидеть обратный URL-адрес в поле адреса браузера.
В рамках настройки Identity Server 4 вы указываете, какие возвращаемые URL-адреса вам разрешено перенаправлять обратно, поэтому я не думаю, что есть какой-либо вред, если пользователи увидят URL-адрес перенаправления.
Следует учитывать, что, если пользователь поделится URL-адресом с кем-то еще в середине процесса аутентификации, смогут ли они возобновить ту часть процесса, которую остановил первоначальный пользователь? это то, что вы хотите в своем приложении?
Если вы имеете в виду надежность, а не безопасность, напишите тесты, которые дадут вам уверенность в том, что ваш код работает.
Спасибо за все материалы. Что касается безопасности, OAuth dotnet core использует одноразовый номер для предотвращения повторов, поэтому я думаю, что эта часть покрыта.
URL-адрес возврата обычно передается как часть процесса входа в систему. Можете ли вы показать, что вы на самом деле пытаетесь сделать и почему поведение по умолчанию не работает для вас?