Совместное использование учетных данных между собственным приложением и веб-сайтом
Приложение, над которым я работаю, позволяет пользователям входить в бэкэнд с поддержкой OAuth. Поэтому приложение привязано только к токенам аутентификации и метаданным пользователя, но не к учетным данным пользователя.
В приложении пользователи могут нажимать ссылки, которые открывают ссылки в браузере. Эти ресурсы также защищены OAuth, и токен, полученный при входе в нативное приложение, также имеет отношение к сети.
Я хотел бы, чтобы учетные данные пользователя передавались из собственного приложения в веб-браузер стандартным способом OAuth (включая его как Authorization заголовок).
Кажется, что Android облегчает это благодаря своей функции общих учетных данных, но я не могу найти эквивалент для iOS. Я нашел функцию общих веб-учетных данных, но, похоже, для этого требуется знание учетных данных пользователя.
Как я могу передавать токены OAuth из моего собственного приложения в открываемые веб-браузеры?
4 ответа
Связанные домены и общие веб-учетные данные не кажутся здесь хорошим подходом.
У вас есть два варианта:
- Передача токена доступа OAuth в виде URL-QueryString-Param в веб-браузер.
https://x.y.z/?access_token=abcВам придется манипулировать встроенными URL-адресами и убедиться, что ваш бэкэнд понимает это. Очень распространенный и легкий подход. Многие сайты, такие как Facebook и Google, передают токены доступа в URL. - Если вы используете In-App-Browsers (UIWebView, WKWebView), вы можете перехватить URL-запрос и добавить заголовок авторизации самостоятельно. Посмотрите это для UIWebView и это для WKWebView (который немного сложнее, чем UIWebView)
Технически, вы можете просто включить токен в URI, который вы передаете браузеру.
Но это было бы небезопасно:
Инъекция токенов доступа
Дополнительная (и очень опасная) угроза возникает, когда клиенты принимают токены доступа из источников, отличных от обратного вызова от конечной точки токена. Это может произойти для клиента, который использует неявный поток (где токен передается непосредственно в качестве параметра в хэше URL-адреса) и неправильно использует параметр состояния OAuth. Эта проблема может также возникать, если различные части приложения передают токен доступа между компонентами, чтобы "делиться" доступом между ними. Это проблематично, потому что это открывает место для потенциальных маркеров доступа, которые могут быть внедрены в приложение внешней стороной (и потенциально могут проникнуть за пределы приложения). Если клиентское приложение не проверяет токен доступа с помощью какого-либо механизма, оно не может отличить действительный токен от токена атаки.
(Источник: https://oauth.net/articles/authentication/)
Также запрещено в спецификации:
Учетные данные токена доступа (а также любые атрибуты токена конфиденциального доступа) ДОЛЖНЫ быть конфиденциальными при передаче и хранении и должны передаваться только серверу авторизации, серверам ресурсов, для которых действителен токен доступа, и клиенту, которому выдан токен доступа.,
(Источник: https://tools.ietf.org/html/rfc6749)
Поэтому вместо этого вы можете попробовать использовать альтернативный поток OAuth, называемый "поток кода авторизации", где вместо передачи токена в браузер приложение передает специальный код, который браузер затем использует для получения токена с сервера.
Однако ваш вариант использования не совсем то, для чего был создан этот механизм, поэтому я не уверен, что его использование для достижения того, что вам нужно, будет соответствовать спецификации.
Сначала вы должны использовать протокол 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.
Никогда не доверяйте пользовательскому вводу.
Почему бы не использовать встроенные функции и библиотеки Apple?
Взгляните на общие веб-учетные данные
Чтобы включить общие учетные данные в вашем приложении, добавьте ключ com.apple.developer.associated-domains к разрешениям вашего приложения. Вы можете добавить это право, используя панель возможностей цели (см. Рисунок 1).
или используя брелок iCloud.
Этот документ посвящен использованию Keychain Services для хранения и получения паролей. Прочтите этот документ, если ваше приложение должно обрабатывать пароли для:
Несколько пользователей - например, сервер электронной почты или сервер планирования, который должен аутентифицировать многих пользователей
Несколько серверов - например, банковское или страховое приложение, которое может обмениваться информацией с несколькими защищенными серверами баз данных.
Пользователь, которому нужно вводить пароли - например, веб-браузер, который может использовать цепочку для ключей для хранения паролей, необходимых пользователю для нескольких безопасных веб-сайтов.
Надеюсь, что это может помочь