Можно ли считать этот поток приложений OAuth2 Native безопасным?

Question

У меня есть провайдер OpenID Connect, созданный на основе IdentityServer4 и ASP.NET Identity, работающий, скажем, на: login.example.com.

У меня работает приложение SPA, скажем, spa.example.com, которое уже использует мой поставщик OpenID Connect для аутентификации пользователей через login.example.com и авторизации их для доступа к SPA.

У меня естьмобильное приложение (нативное на обеих платформах), которое на данный момент использует собственную систему аутентификации.

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

Итак, я начал с просмотра веб-сайта OpenID connect и перечитал RFC6749 , после нескольких поисков в Google я понял, что это общая проблема, и обнаружил RFC8252 (OAuth2для собственных клиентов), а также динамическая регистрация клиентов ( RFC7591 ) и PKCE ( RFC7636 ).

Я почесал голову из-за того, что больше не было возможности хранить какие-либо «секретные» данные на клиенте / стороннем устройстве (нативные приложения), поскольку они могли быть скомпрометированы.

Я обсудил эту тему с некоторыми коллегами, и мы предложили следующую настройку:

1. Свяжите домен, скажем app.example.com, с моим мобильным приложением с помощью Apple Universal Links и Android Ссылки на приложения .
2. Используйте поток AuthenticationCode для обоих клиентов и заставьте их использовать PKCE.
3. Используйте redirect_uri в домене, связанном с приложениемскажем: https://app.example.com/openid
4. Заставьте пользователя всегда давать согласие на вход в приложение после входа в систему, поскольку ни iOS, ни Android не вернут приложение, выполнив автоматическое перенаправление, это должен быть пользователькоторый каждый раз вручную щелкает ссылку универсального / приложения.

Я использовал библиотеку AppAuth в обоих приложениях, и сейчас все отлично работает на test , но мне интересно:

1. Считаете ли вы, что это безопасный способ избежать того, чтобы кто-либо, обладающий необходимыми навыками, мог выдать себя за мои приложения или каким-либо другим способом получить несанкционированный доступ к моим API?Какова текущая лучшая практика для достижения этой цели?
2. Есть ли способ избежать того, чтобы пользователь всегда "соглашался" (когда он фактически нажимал на ссылку универсального / приложения).
3. Я также отметил, что Facebook использует свое приложение в качестве своего рода сервера авторизации, поэтому, когда я нажимаю «singing in facebook» в приложении, я попадаю на страницу facebook, которая спрашивает меня, хочу ли яmsgstr "запустить приложение для входа в систему".Я хотел бы знать, как я могу добиться чего-то подобного, чтобы позволить моим пользователям входить в SPA по телефону, используя мое приложение, если оно установлено, как это делает Facebook со своими приложениями.

Answer 1

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

Это то, что вам предоставляют OAuth 2.0 и OpenID Connect.Возможность использовать единый идентификатор пользователя среди разных сервисов.Так что это правильный подход.

больше не было возможности хранить какие-либо «секретные данные» на клиенте / стороннем устройстве (нативные приложения), так как это могло стать скомпрометированным

Правильно.С точки зрения спецификации OAuth 2.0 они называются публичные клиенты .Им не рекомендуется иметь клиентские секреты, связанные с ними.Вместо этого для проверки запроса токена в провайдере идентификации используется код авторизации, идентификатор приложения и URL-адрес перенаправления.Это делает код авторизации ценным секретом.

Свяжите домен, скажем, app.example.com, с моим мобильным приложением, используя Apple Universal Links и Android App Links.

Не эксперт в области мобильных устройств.Но да, пользовательские домены URL - это способ обработки перенаправления для OAuth и OpenID Connect.

Также использование PKCE является правильным подходом.Следовательно, перенаправление происходит в браузере (пользовательский агент), могут быть злоумышленники, которые могут получить код авторизации.PKCE избегает этого, вводя секрет, который не будет открыт пользовательскому агенту (браузеру).Секрет используется только в запросе токена (прямое HTTP-соединение), поэтому является безопасным.

Q1

Использование потока кода авторизации с PKCE является стандартной передовой практикой, рекомендованной спецификациями OAuth.,Это справедливо и для OpenID Connect (следовательно, он построен на OAuth 2.0)

Следует отметить, что, если вы считаете, что секрет PKCE может быть использован, то это буквально означает, что устройство взломано.Подумайте об извлечении секрета из памяти ОС.это означает, что система взломана (вирус / кейлоггер или как мы их называем).В таком случае конечному пользователю и вашему приложению есть о чем беспокоиться.

Кроме того, я считаю, что это для бизнес-приложений.В этом случае ваши клиенты обязательно получат руководство по безопасности для своих устройств.Например установка антивирусов и ограничения установки приложения.Чтобы предотвратить атаки, упомянутые выше, нам придется полагаться на такие учреждения безопасности.Один OAuth 2.0 не является безопасным.Вот почему существуют руководства по лучшей практике ( RFC68129 ) и правила.

Q2

Не ясно по этому вопросу.Страница согласия представлена ​​от провайдера идентификации.Так что это будет конфигурация этой системы.

Q3

Ну, Identity Provider может поддерживать сеанс единого входа в браузере.Страница входа присутствует в этом браузере.Поэтому в большинстве случаев, если приложение использует один и тот же браузер, пользователи должны иметь возможность использовать SPA без входа в систему.

Answer 2

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

Из UX PoV Я думаю, что имеет смысл минимизировать случаи, когда браузерна основе знака в потоке используется.Я бы использовал функции безопасности платформы (например, безопасный анклав на iOS) и оставил там маркер обновления, как только пользователь войдет в систему в интерактивном режиме, а затем он сможет войти в систему, используя свой PIN-код, отпечаток пальца или лицо и т. Д.