Доля учетных данных между родным приложением и веб-сайтом

Приложение, над которым я работаю, позволяет пользователям входить в бэкэнд с поддержкой OAuth. Таким образом, приложение предназначено только для токенов аутентификации и пользовательских метаданных, а не для учетных данных пользователя.

В приложении пользователи могут удалять ссылки, открывающие ссылки в браузере. Эти ресурсы также защищены OAuth, а токен, полученный при входе в собственное приложение, также имеет отношение к сети.

Я хотел бы, чтобы учетные данные пользователя переходили из собственного приложения в веб-браузер стандартным способом OAuth (включив его как заголовок Authorization).

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

Как я могу передать токены OAuth из моего собственного приложения через веб-браузеры, которые он открывает?

Ответ 1

Связанные домены и общие учетные данные в Интернете, похоже, не являются хорошим подходом.

У вас есть два варианта:

Передача токена доступа OAuth в виде URL-QueryString-Param для Веб-браузер. https://x.y.z/?access_token=abc Вам нужно будет манипулировать внедренными URL-адресами и убедиться, что ваш бэкэнд понимает это. Очень распространенный и легкий подход. Многие веб-сайты, такие как Facebook и Google пропускает токены доступа в URL-адресе.
Если вы используете In-App-Browsers (UIWebView, WKWebView), вы можете перехватить URL-запрос и добавить заголовок авторизации самостоятельно. См. this для UIWebView и this для WKWebView (что немного сложнее, чем UIWebView).

Ответ 2

Технически вы можете просто включить токен в URI, который вы передаете в браузер.

Но это было бы неуверенно:

Инъекция токенов доступа

Дополнительная (и очень опасная) угроза возникает, когда клиенты принимают токены доступа из других источников, кроме обратный вызов с конечной точки маркера. Это может произойти для клиента, который использует неявный поток (где токен передается непосредственно как параметр в хеше URL-адреса) и неправильно использовать состояние OAuth параметр. Эта проблема также может возникать, если различные части приложение передает токен доступа между компонентами, чтобы "поделиться" доступом между ними. Это проблематично, поскольку оно открывает место для токенов доступа, которые потенциально могут быть введены в приложение (и, возможно, утечка вне приложения). Если клиентское приложение не проверяет токен доступа через в некотором механизме, он не имеет возможности дифференцировать действительный токен и токен атаки.

(Источник: https://oauth.net/articles/authentication/)

В спецификации также запрещено:

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

(Источник: https://tools.ietf.org/html/rfc6749#section-10.3)

Вместо этого вы можете попробовать использовать альтернативный поток OAuth, называемый "поток кода авторизации", где вместо передачи маркера в браузер приложение передает специальный код, который браузер затем использует для получения токена из сервер.

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

Ответ 3

Сначала вы должны использовать протокол HTTPS - google для: позволить шифровать (чтобы получить бесплатный сертификат SSL)

Поток, который вы должны учитывать:

Пользователь открывает ваше мобильное приложение и запрашивает его имя пользователя или электронной почты и пароль.
Вы отправляете запрос POST из своего мобильного приложения в службу API с именем пользователя пользователя или данными электронной почты и паролем (OVER SSL!).
Вы проверяете учетные данные пользователя и создаете токен доступа для пользователь, который истекает через определенное время. (google для: ограничение скорости api)
Вы сохраняете этот токен доступа на мобильном устройстве, рассматривая его как ключ API, который позволяет вам получить доступ к вашей службе API.
Как только токен доступа истекает и больше не работает, вы повторно запрашиваете пользователь для их имени пользователя или электронной почты и пароля.

На стороне сервера вы должны использовать такие вещи, как: fail2ban, iptables и убедитесь, что версия Linux, которую вы используете, обновлена. (вы должны время от времени обновлять/обновлять)

В веб-приложении (api) вы должны проверить и сериализовать все данные. Никогда не отправляйте больше данных, которые необходимы, и никогда не принимайте частичные данные от клиента. В приложении api вы должны выполнить xss (межсайтовый скриптинг)/csrf (перекрестная проверка подделки сайта). Взгляните на OWASP TOP 10 - https://www.owasp.org/index.php/Top_10_2013-Top_10. Вы также должны использовать заголовки безопасности - https://www.dionach.com/blog/an-overview-of-http-security-headers на веб-странице api.

Никогда не доверяйте пользовательскому вводу.

Ответ 4

Почему бы не использовать встроенные функции и библиотеки Apple?

Посмотрите общедоступные учетные данные

Чтобы включить общие учетные данные в вашем приложении, добавьте ключ com.apple.developer.associated-domains в свои права на приложения. Вы можете добавить это право, используя панель возможностей целей (см. Рис. 1).

или используя iCloud Keychain.

В этом документе основное внимание уделяется использованию служб Keychain для хранения и извлечения паролей. Прочтите этот документ, если ваше приложение должно обрабатывать пароли для:

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

Несколько серверов - например, банковское или страховое приложение, которым, возможно, придется обмениваться информацией с более чем одним безопасным сервером базы данных.

Пользователь, которому необходимо вводить пароли - например, веб-браузер, который может использовать цепочку ключей для хранения паролей, которые пользователь должен использовать для нескольких защищенных веб-сайтов

Надеюсь, что это поможет