Разница между токеном AD, полученным с помощью ADAL и ADAL JS

У меня есть уникальный сценарий, в котором аутентификация выполняется в Azure AD с использованием ПО промежуточного слоя Open ID Connect. Теперь, когда приложение аутентифицировано и сеанс установлен, мне нужно будет выполнять вызовы AJAX к службам WebAPI, расположенным на том же сервере.

Я планирую вернуть кешированный на сервере токен идентификатора/доступа обратно клиенту и сохранить его в хранилище сеансов.

Есть ли какие-либо последствия для безопасности с этим подходом, я имею в виду, есть ли разница между токеном, полученным через ADAL JS или ADAL?


person deepesh    schedule 12.02.2016    source источник


Ответы (1)


Я не рекомендую делать это. Маркеры доступа и идентификатора, полученные конфиденциальным клиентом, отличаются от маркеров, полученных общедоступным, а в маркерах Azure AD, выпущенных через неявный поток, есть дополнительные отличия из-за эвристики, направленной на сдерживание их размера. Существует более чистое решение для вашего сценария. После того как вы вошли в систему с помощью OpenID Connect, в вашем браузере есть файл cookie сеанса с Azure AD. Если вы внедряете на свои страницы скрытый iframe и используете этот iframe для управления неявными запросами на предоставление токенов через javascript, вы можете заставить свой JS-интерфейс получать свои собственные токены без необходимости распространять токены, полученные где-либо еще в вашей топологии. Это именно то, что ADAL делает для обновления маркеров и для получения новых маркеров после входа в систему. К сожалению, у нас нет примеров для этого подхода, но вы можете изучить исходный код ADAL JS, чтобы увидеть, как это работает.

person vibronet    schedule 12.02.2016
comment
Спасибо, это проясняет, но каковы последствия для безопасности при передаче токена, полученного через конфиденциальный клиент, не могли бы вы указать мне нужное место, чтобы найти дополнительную информацию по этому вопросу? - person deepesh; 16.02.2016