Одинарная конечная точка AuthZ/AuthN в DotNetOpenAuth2

Я работаю над внедрением сервера аутентификации, который обеспечит единый вход для веб-приложений, которые производит наша компания, и я работаю с DotNetOpenAuth2 на данный момент. Моя проблема заключается в том, что DNOA работает так (из книги Apress Pro ASP.NET Web API Security от Badrinarayanan Lakshmiraghavan)

DotNetOpenAuth Protocol

Но я хочу, чтобы он работал так (этот образ я редактировал):

enter image description here

Есть ли способ заставить это сделать это или другую структуру, которую я должен использовать вместо этого? Я хочу сделать это, чтобы сделать безопасность более простой и понятной для более поздних разработчиков. Ниже приводится объяснение, почему это было бы хорошо для моих целей.

Все наши веб-приложения поддерживают HTTPS и находятся в 1 из 2 родительских доменов (поэтому каждый веб-сервер имеет 2 сертификата x509, которые поддерживают SSL на таких поддоменах, как *.domain1.com или *.domain2.com).

Мой план состоит в том, чтобы использовать существующие сертификаты как неявно разделяемый секрет для шифрования токенов, отчеканенных DotNetOpenAuth2. Поэтому при создании токенов AuthorizationServerAccessToken.ResourceServerEncryptionKey будет открытым ключом сертификата SSL, а AuthorizationServerAccessToken.AccessTokenSigningKey будет закрытым ключом сертификата SSL.

Таким образом, любой из моих серверов имеет возможность дешифровать токен пользователя и получать от него утверждения об авторизации безопасным способом. Учитывая простоту схемы, я просто хочу, чтобы одна конечная точка auth получала имя пользователя и пароль и возвращала зашифрованный токен.

Похоже, это упрощение делает вещи более безопасными и более простыми в реализации. Тем более, что мы можем покончить с nonce. Одна из возможных недостатков заключается в том, что злоумышленник, который получает доступ к закрытому ключу веб-сертификата, также сможет обманывать токены пользователя auth. Но кажется, что если ваши сертификаты SSL не были скомпрометированы, это хорошо соблюдение правил безопасности, учитывая, что безопасность веб-приложений обычно полностью зависит от этого предположения. И я все равно не храню конфиденциальную информацию в токенах, а только флаги разрешений.

+2
источник поделиться
2 ответа

Основная цель вашей диаграммы состоит в том, чтобы вырезать шаги обмена кодом авторизации и просто доставить токен доступа. Вот связанный пост, который я рекомендую прочитать, чтобы убедить себя в этом полезности этого шага. Кроме того, действительно ли вы хотите создать свой собственный протокол авторизации OAuth2.0 только потому, что OAuth2.0 запутан? Я думаю, что, поскольку все больше разработчиков принимают OAuth2.0, концепции начинают чувствовать себя менее чужими.

+1
источник

Я очень высоко рекомендую IdentityServer для того, что вы ищете. Я нахожусь на грани создания IdentityServer для своей компании, а также после того, как начальная игра с ней показала, что это лучшее решение для "броска вашего собственного". Другая приятная часть заключается в том, что аутентификация отделена от авторизации, позволяя вам в будущем заменять поставщиков удостоверений (например, если вы хотите сменить идентификаторы арендаторов по дороге) или добавить несколько арендаторов Azure AD.

Кроме того, у вас будет намного лучший контроль над претензиями, которые вы хотите передать пользователям или демонам.

+1
источник

Посмотрите другие вопросы по меткам или Задайте вопрос