Nano Hash - криптовалюты, майнинг, программирование

Как избежать отображения экрана согласия в наших собственных приложениях при внешней аутентификации?

Фон

  • Мы разработали веб-приложение с rest-api с использованием oauth2/oidc и поддержкой сторонних приложений.
  • Мы разработали собственные нативные приложения для Android и iOS. В настоящее время они извлекают долгоживущий токен из потока учетных данных пользователя (экран согласия не требуется).
  • В настоящее время мы расширяем наш поток аутентификации, чтобы также принимать внешний вход через google/office365. Это также поддерживается путем указания значения acr в коде авторизации/неявном потоке oauth.

Вопрос/проблема

  • Мы, конечно, хотим иметь возможность полностью доверять нашему родному приложению и не показывать экран согласия для лучшего взаимодействия с пользователем. Однако при использовании кода авторизации/неявного потока ничто не может считаться секретом, и злонамеренный хакер может потенциально использовать (без ведома пользователя) пользователя, если не отображается экран согласия.
  • Как мы можем избежать необходимости показывать экран согласия для нашего собственного приложения, но при этом быть уверенными, что пользователь максимально безопасен?

Как решить?

  1. Выполнение отдельного входа в систему office365/google для получения токена обновления из этого idp, а затем реализация способа публичной аутентификации с использованием этого токена для получения долгоживущего токена из нашего веб-приложения.
  2. Просто игнорируйте недостатки безопасности и никогда не спрашивайте согласия пользователя, учитывая несекретную смесь `clientId/clientSecret/redirectUrl` под предлогом «это довольно сложно взломать».
  3. Игнорирование недостатков безопасности, если внешний вход в систему с оправданием «google/office365 должен в любом случае отображать экран согласия при запросе токена обновления».
  4. Какой-то неизвестный способ убедиться, что это не вредоносное приложение/пользователь

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

Есть ли что-то, что мне здесь не хватает, что будет считаться лучшей практикой?

authentication android security oauth-2.0 openid-connect
02.10.2015

  • Разве не было бы способа сделать это похоже на веб-приложение? Тогда у вас есть те же свойства - clientId/secret живет в веб-приложении, и родное приложение должно пройти этот путь, чтобы получить к нему доступ? Конечно, конечные точки веб-приложений могут быть использованы не по назначению, но это верно и для обычных веб-приложений… 08.10.2015
  • Чем это отличается от того, чтобы не проходить проверку безопасности веб-приложений? 09.10.2015
  • Безопасность становится прежней. Веб-приложение имеет собственный специализированный бэкэнд и, возможно, не будет раскрывать профиль аутентифицированных пользователей, в зависимости от цели приложения. Если веб-приложение раскрывает что-то, для чего требуется определенный идентификатор клиента, это может быть использовано так же неправильно, как и идентификация клиента приложения. Возможно, это не решит ваших проблем, но их должно считать похожими, если вы относитесь к приложению так же, как к браузеру. 09.10.2015

Ответы:


1

Дело в том, что Google необходимо аутентифицировать пользователя за пределами вашего приложения, чтобы убедиться, что ваше приложение не увидит учетные данные пользователя и, таким образом, сведет на нет цель OAuth.

Пользователь также должен явно разрешить приложению, чтобы случайные приложения не получали токены от пользователя: любой, у кого есть учетная запись Google, может создать комбинацию client_id/client_secret/redirect_uri. Google не доверяет вам/вашему приложению токены для произвольных пользователей без предварительного запроса этих пользователей. Как вы упомянули в (1), пользователю нужно пройти через это только один раз. Приложение может получить долгоживущий токен обновления и продолжать использовать его для обновления токенов доступа.

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

02.10.2015
  • Возможно, небольшое недоразумение, чего мы хотим избежать, так это экрана согласия, который наше собственное приложение показывает для всех нативных приложений, использующих веб-просмотр. В сочетании с аутентификацией google/o365 это будет означать, что на самом деле есть один экран согласия для каждого ресурса (google и нас). Для наших собственных (и надежных) приложений мы ищем способ избежать нашего собственного экрана согласия при использовании внешней аутентификации. 05.10.2015

    • 2

    Я бы сказал что-то вроде № 2:

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

    Секрет клиента должен быть безопасным; если это не так, у вас есть другие проблемы с безопасностью.

    05.10.2015
  • ClientSecret в нативном приложении считается небезопасным, для других веб-приложений мы уже делаем это. 06.10.2015
  • Вы правы… Я больше привык думать в веб-приложениях. 08.10.2015
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..