В разделе спецификации OAuth 2.0 * содержится одна ключевая информация о проблеме, которую он пытается решить. Я выделил раздел ниже,
В традиционной модели аутентификации клиент-сервер клиент
запрашивает ресурс с ограниченным доступом (защищенный ресурс) на
аутентификация на сервере с использованием ресурса владельца
Полномочия . Для предоставления сторонним приложениям доступа к
ограниченные ресурсы, владелец ресурса делится своими учетными данными с
третье лицо
В качестве резюме, что OAuth хочет предоставить, это уровень авторизации, который устраняет требование предоставления учетных данных конечного пользователя третьей стороне. Для достижения этого он представляет несколько потоков (например: поток кода авторизации, неявный поток и т. Д.) Для получения токенов, которые достаточно хороши для доступа к защищенным ресурсам.
Но не все клиенты могут принять эти потоки. Именно по этой причине спецификация OAuth вводит ROPF . Это выделено из следующего извлечения,
Тип предоставления учетных данных пароля владельца ресурса подходит в
случаи, когда владелец ресурса имеет доверительные отношения с
клиент, такой как операционная система устройства или высоко привилегированный
Сервер авторизации должен проявлять особую осторожность при
разрешить этот тип предоставления и разрешать его только тогда, когда другие потоки не
жизнеспособными.
Согласно вашему объяснению, у вас есть доверительные отношения с клиентом. И ваш поток, кажется, работает нормально. Но с моей стороны я вижу следующие проблемы.
Trust
Доверие между конечным пользователем и клиентским приложением. Когда вы выпустите и будете использовать его в качестве продукта, ваши конечные пользователи будут доверять вашему клиенту и предоставлять свои учетные данные? Например, если вашим сервером идентификации является Azure AD, конечные пользователи будут предоставлять учетные данные Azure вашему клиенту .?
Доверие может не быть проблемой, если вы используете один идентификационный сервер, и он будет единственным, который вы когда-либо будете использовать. Что приносит нам следующую проблему,
Поддержка нескольких серверов идентификации
Одно преимущество, которое вы получаете с OAuth 2 и OpenID Connect, - это возможность использовать несколько серверов идентификации. Например, вы можете перемещаться между Azure AD, Identityserver или другими серверами идентификации, которые выбираются клиентом (например, они уже используют внутренне и хотят, чтобы ваше приложение им пользовалось). Теперь, если ваше приложение хочет использовать такие серверы идентификации, конечные пользователи должны будут предоставить учетные данные вашему клиенту. Иногда эти серверы идентификации могут даже не поддерживать поток ROPF. И все же снова ДОВЕРИЕ стало проблемой.!
Решение?
Ну, я вижу один хороший поток, который вы можете использовать. У вас есть один сервер переднего плана и внутренний сервер. Я считаю, что ваш клиент является комбинацией обоих. Если это так, вы можете попытаться принять поток кода авторизации. Это правда, что ваш интерфейс - это SPA. Но у вас есть бэкэнд, который вы можете использовать для получения токенов. Единственная задача состоит в том, чтобы соединить внешний SPA-интерфейс с внутренним для ответа токена (передать токен доступа в SPA и сохранить другие токены во внутреннем интерфейсе). При таком подходе вы избежите вышеупомянутых проблем.