У нас есть аутентификационная инфраструктура на основе OAuth2, которая интегрирована в различные веб-приложения внутри нашей организации.У нас также есть чистое нативное приложение без собственного промежуточного программного обеспечения, и мы хотим интегрировать аутентификацию в это нативное приложение.Это приложение уже имеет свой собственный внутренний механизм входа в систему с собственным экраном входа в систему, и мы не хотим, чтобы оно начало запускать внешние компоненты, такие как веб-браузеры, для отображения окон входа в систему.Мы являемся как поставщиком приложений, так и поставщиком аутентификации, поэтому проблема, связанная с тем, что приложение может видеть учетные данные пользователя, составляет меньше проблемы - мы верим, что не намеренно сделаем что-либок учетным данным пользователя, и те же люди пишут форму входа в приложение, как и на веб-сайте.: -)
Мы пытаемся выяснить, как лучше поддерживать, чтобы приложение продолжало собирать учетные данные, как это происходит сейчас, но используем их для получения токена авторизации в нашей среде аутентификации.Сейчас, когда API-интерфейсы установлены, единственный способ, которым я могу убедиться, - это внедрить Client Secret в собственное приложение, чтобы оно могло использовать запрос на предоставление учетных данных для владельца ресурса, поскольку код, который обычно выполняетсяу этого вызова нет серверной стороны, чтобы жить. Это кажется действительно неправильным , так или иначе.: -P
Насколько я понимаю, многие структуры OAuth на самом деле не применимы к этому приложению, потому что оно не живет в контексте веб-браузера, оно не имеет никакой концепции«домена», ни каких-либо «междоменных» ограничений.Было высказано предположение, что, возможно, мы создадим промежуточное программное обеспечение для этого приложения всего с целью обмена кодами аутентификации для токенов, но обоснование этого заключается в том, что это промежуточное программное обеспечение теоретически должно бытьв состоянии каким-то образом проверять запросы, чтобы определить, законно ли они поступили из приложения, и я не вижу способа сделать это так, чтобы никто не мог имитировать доступ к коду клиентского приложения.По сути, единственной целью, которой могло бы служить такое промежуточное программное обеспечение, было бы сделать Client Secret не имеющим отношения к получению аутентификационных кодов для учетных данных.
Одна мысль, которая пришла к нам, заключалась в том, как что-то вроде Windows делает это?Очевидно, что в Windows используется собственная форма входа в систему, но существует некоторый поток, в соответствии с которым введенные учетные данные используются для аутентификации и, по-видимому, глубоко внутри системы для получения токена авторизации.Кто-нибудь знает, документирована ли эта архитектура где-нибудь?Имеет ли архитектурный выбор Microsoft какое-либо отношение к OAuth2?Какова «лучшая практика» для приложения, если вы воспринимаете его как с учетом , что оно не имеет промежуточного программного обеспечения и имеет собственную собственную форму входа в систему?