Последние несколько дней я потратил на подготовку и запуск реализации OAuth.Не на Android, а на моем веб-сервере, который будет выступать в качестве прокси для защищенной службы OAuth.Я как раз собираюсь внедрить свой Android-клиент, и моя голова все еще волнуется из-за проблем безопасности и реализации.
OAuth достаточно грязный, когда клиент просто веб-браузер.У вас есть следующий ряд шагов:
- (клиентский веб-браузер) сделать запрос на мой прокси-сервер
- (прокси-сервер) запросить неавторизованный токен от поставщика OAuth (например, API веб-службы))
- (прокси-сервер) попросить поставщика OAuth разрешить пользователю авторизовать токен.После того, как пользователь завершит авторизацию, перенаправьте веб-браузер на URI авторизации поставщика OAuth
- (провайдер OAuth), перенаправьте браузер на ваш URI обратного вызова
- (прокси-сервер :: URI обратного вызова) токен авторизации Exchange дляполучить доступ к токену и сохранить его для будущих вызовов
- Выполнять вызовы API для поставщика OAuth и возвращать ответный документ в веб-браузер клиента
Теперь этого вполне достаточно.Но при использовании той же механики с мобильным приложением в качестве клиента оно становится еще более сложным.Проблема, конечно, заключается в том, что вам нужно сделать акробатику, чтобы добавить сеанс браузера в поток кода вашего мобильного приложения во время танца OAuth.Это означает, что вам нужно еще больше усложнить танец OAuth следующим образом (я использую приложение Android для этого примера, чтобы конкретизировать):
- (мобильное веб-приложение :: собственный код) сделать запрос от проксисервер, использующий Java / HTTP
- (прокси-сервер), запрашивает несанкционированный токен от поставщика OAuth (например, API веб-службы)
- (прокси-сервер) возвращает ответный документ в мобильное веб-приложение, содержащееURI перенаправления для авторизации пользователя провайдером OAuth, желательно, чтобы скрыть ключ потребителя и другие детали для предотвращения отслеживания по беспроводной сети.
- (мобильное веб-приложение). Запустите действие веб-браузера с авторизацией.URL с установленным фильтром намерений.Однако сохраните и замените указанный обратный URI прокси-сервера специальным «фальшивым» URI, созданным для простой идентификации URI фильтром намерений (см. Следующие шаги)
- (поставщик OAuth) после того, как пользователь завершит авторизацию, перенаправьте браузерна ваш «фальшивый» URI обратного вызова.
- (мобильное веб-приложение) Фильтр намерений обнаруживает «фальшивый» URI обратного вызова и использует этот сигнал для восстановления контроля.Перестройте URI обратного вызова прокси-сервера и используйте Java / HTTP для выполнения запроса.
- (proxy server :: callback URI) Токен авторизации Exchange для токена доступа, а затем сохраните его для будущих вызовов, как и раньше
- Выполнять API-вызовы поставщику OAuth и возвращать ответный документ в мобильное веб-приложение
Это довольно отвратительно, как вы можете видеть.Если есть гораздо более простой способ сделать это, то я очень хочу это услышать.Насколько я знаю, есть только две другие альтернативы, каждая из которых имеет свои существенные проблемы.
1) Забудьте о прокси-сервере и делайте все прямо из мобильного веб-приложения.Большая дыра в безопасности заключается в том, что вы должны «запекать» свой потребительский ключ OAuth и хранить секрет в своем приложении.Если злоумышленник декомпилирует ваш код и отыщет эти строки - довольно простая операция для тех, кто имеет опыт обратного инжиниринга, он может нанести ущерб вашему приложению и пользователям.
2) Переключитесь на XAuth, где пользователь предоставляет вам свои логин и пароль, и вы «соглашаетесь» не сохранять их и обменивать их напрямую на токен доступа с сервером XAuth. Первая проблема - завоевание доверия пользователей к предоставлению этой информации, проблема, которую OAuth был создан для решения, и, конечно, как насчет людей, которые не соблюдают свое обязательство отказаться от данных для входа? Хуже того, сервер XAuth должен поддерживать XAuth и предлагать HTTPS (SSL) соединения, и я видел множество веб-API, которые тоже не поддерживают. Разумеется, SSL-соединение необходимо, потому что без него вы будете отправлять имя пользователя и пароль по сети в виде простого текста при выполнении запроса XAuth.
http://blog.zyber17.com/post/1283741364/why-xauth-is-a-really-dumb-idea
К вашему сведению, хотя он не использует прокси-сервер, следующий пример иллюстрирует метод, который я описал выше, для внедрения сеанса браузера в OAuth-взаимодействие вашего мобильного приложения и перехвата URI обратного вызова:
http://blog.doityourselfandroid.com/2010/11/10/oauth-flow-in-android-app/
Так что это выглядит довольно уродливо, когда вы на него смотрите, и я даже не стал испытывать дополнительное раздражение от создания и управления вашим собственным идентификатором пользователя для пользователя, чтобы вы могли посмотреть его токены доступа, хранящиеся на вашем прокси-веб-сервере. правильно (включая беспорядочный ввод еще одного PIN-кода или кода доступа для пользователя).
Интересное примечание: проводя некоторые исследования безопасности сеансов веб-браузера Android, я с удовлетворением обнаружил, что у вас нет доступа к текущей веб-странице HTML. Если бы вы могли получить к нему доступ, то враждебный Android-кодировщик мог бы с легкостью перехватить логин и пароль пользователя, тем самым полностью разрушив цель и намерение OAuth. Я был встревожен, узнав, что может быть способ получить этот HTML с помощью объекта CacheManager. Любопытно, что этот объект теперь устарел и планируется удалить в соответствии с документацией по Android, поэтому мы надеемся, что это означает, что Google обнаружил (потенциальную) дыру в безопасности и предпринимает шаги по ее удалению в следующей сборке:
http://developer.android.com/reference/android/webkit/CacheManager.html
В заключение я хотел бы услышать мысли тех, кто боролся с этими же проблемами при создании своих приложений OAuth.
- Рошлер