Одинарная конечная точка AuthZ/AuthN в DotNetOpenAuth2
Я работаю над внедрением сервера аутентификации, который обеспечит единый вход для веб-приложений, которые производит наша компания, и я работаю с DotNetOpenAuth2 на данный момент. Моя проблема заключается в том, что DNOA работает так (из книги Apress Pro ASP.NET Web API Security от Badrinarayanan Lakshmiraghavan)
Но я хочу, чтобы он работал так (этот образ я редактировал):
Есть ли способ заставить это сделать это или другую структуру, которую я должен использовать вместо этого? Я хочу сделать это, чтобы сделать безопасность более простой и понятной для более поздних разработчиков. Ниже приводится объяснение, почему это было бы хорошо для моих целей.
Все наши веб-приложения поддерживают HTTPS и находятся в 1 из 2 родительских доменов (поэтому каждый веб-сервер имеет 2 сертификата x509, которые поддерживают SSL на таких поддоменах, как *.domain1.com или *.domain2.com).
Мой план состоит в том, чтобы использовать существующие сертификаты как неявно разделяемый секрет для шифрования токенов, отчеканенных DotNetOpenAuth2. Поэтому при создании токенов AuthorizationServerAccessToken.ResourceServerEncryptionKey будет открытым ключом сертификата SSL, а AuthorizationServerAccessToken.AccessTokenSigningKey будет закрытым ключом сертификата SSL.
Таким образом, любой из моих серверов имеет возможность дешифровать токен пользователя и получать от него утверждения об авторизации безопасным способом. Учитывая простоту схемы, я просто хочу, чтобы одна конечная точка auth получала имя пользователя и пароль и возвращала зашифрованный токен.
Похоже, это упрощение делает вещи более безопасными и более простыми в реализации. Тем более, что мы можем покончить с nonce. Одна из возможных недостатков заключается в том, что злоумышленник, который получает доступ к закрытому ключу веб-сертификата, также сможет обманывать токены пользователя auth. Но кажется, что если ваши сертификаты SSL не были скомпрометированы, это хорошо соблюдение правил безопасности, учитывая, что безопасность веб-приложений обычно полностью зависит от этого предположения. И я все равно не храню конфиденциальную информацию в токенах, а только флаги разрешений.
Основная цель вашей диаграммы состоит в том, чтобы вырезать шаги обмена кодом авторизации и просто доставить токен доступа. Вот связанный пост, который я рекомендую прочитать, чтобы убедить себя в этом полезности этого шага. Кроме того, действительно ли вы хотите создать свой собственный протокол авторизации OAuth2.0 только потому, что OAuth2.0 запутан? Я думаю, что, поскольку все больше разработчиков принимают OAuth2.0, концепции начинают чувствовать себя менее чужими.
Я очень высоко рекомендую IdentityServer для того, что вы ищете. Я нахожусь на грани создания IdentityServer для своей компании, а также после того, как начальная игра с ней показала, что это лучшее решение для "броска вашего собственного". Другая приятная часть заключается в том, что аутентификация отделена от авторизации, позволяя вам в будущем заменять поставщиков удостоверений (например, если вы хотите сменить идентификаторы арендаторов по дороге) или добавить несколько арендаторов Azure AD.
Кроме того, у вас будет намного лучший контроль над претензиями, которые вы хотите передать пользователям или демонам.
Связанные вопросы
Похожие вопросы
Посмотрите другие вопросы по меткам authentication c# access-token dotnetopenauth или Задайте вопрос