Блог

Моя команда и я работали над веб-приложением для наших клиентов, которое использует веб-токены JSON для аутентификации и авторизации. Используя Azure AD в качестве поставщика удостоверений личности, мы проверяем личность пользователя и создаем подписанный JWT с указанными в нем разрешениями пользователя. Затем JWT включается в заголовок авторизации всех последующих запросов к API. Довольно стандартные вещи, насколько это касается JWT.

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

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

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

Я не эксперт по безопасности и не утверждаю, что знаю, существует ли вообще правильный способ делать подобные вещи, но с моей точки зрения это не кажется намного менее безопасным, чем любой другой механизм аутентификации и авторизации с использованием JWTs. Это правда? Мы что, спятили, что даже попытались? Есть ли более безопасный способ сделать это? Что я должен знать об этом, чего я явно еще не знаю?

Заранее спасибо за помощь. По крайней мере, я надеюсь, что это подтолкнет к какому-нибудь полезному разговору.

Единый вход (единый вход) позволяет пользователям вводить свои учетные данные один раз для входа в систему и создания сеанса, который можно повторно использовать в нескольких приложениях без необходимости повторной аутентификации. Это обеспечивает удобство работы для пользователя и уменьшает количество повторяющихся запросов на ввод учетных данных. Azure AD предоставляет приложениям возможности единого входа, устанавливая файл cookie сеанса при первой проверке подлинности пользователя. The MSAL.js библиотека позволяет приложениям использовать это несколькими способами.

MSAL использует файл cookie сеанса для обеспечения единого доступа пользователя между различными приложениями.

Подробнее читайте в этой документации.