Последние несколько дней я потратил на то, чтобы внедрить OAuth и запустить ее. Не на Android, а на моем веб-сервере, который будет действовать как прокси для службы, защищенной OAuth. Я как раз собираюсь реализовать свой Android-клиент, но моя голова все еще волнуется над проблемами безопасности и реализации.
OAuth достаточно беспорядочный, когда клиентом является просто веб-браузер. У вас есть следующая последовательность шагов:
- (клиентский веб-браузер) запросить мой прокси-сервер
- (прокси-сервер) запрашивает неавторизованный токен у поставщика OAuth (например, API веб-службы)
- (прокси-сервер) попросить провайдера OAuth разрешить пользователю авторизовать токен. Перенаправить веб-браузер на URI авторизации провайдера OAuth
- (Провайдер OAuth) после того, как пользователь завершит авторизацию, перенаправляет браузер на ваш URI обратного вызова
- (прокси-сервер :: URI обратного вызова) Обменять токен авторизации на токен доступа, а затем сохранить его для будущих вызовов
- Выполнять вызовы API к провайдеру OAuth и возвращать ответный документ клиентскому веб-браузеру.
Теперь этого вполне достаточно. Но при использовании того же механизма с мобильным приложением в качестве клиента он становится еще более активным. Проблема, конечно, в том, что вам нужно выполнить некоторые акробатические трюки, чтобы внедрить сеанс браузера в поток кода вашего мобильного приложения во время танца OAuth. Это означает, что вам нужно еще больше усложнить танец OAuth следующим образом (я использую приложение для Android для этого примера, чтобы сделать вещи конкретными):
- (мобильное веб-приложение :: собственный код) сделать запрос с прокси-сервера, используя Java / HTTP
- (прокси-сервер) запрашивает неавторизованный токен у поставщика OAuth (например, API веб-службы)
- (прокси-сервер) возвращает ответный документ мобильному веб-приложению, который содержит URI перенаправления для авторизации пользователя поставщиком OAuth, предпочтительно запутанный, чтобы скрыть ключ потребителя и другие детали, чтобы предотвратить отслеживание "по воздуху".
- (мобильное веб-приложение) Запустите действие веб-браузера с URL-адресом авторизации с установленным фильтром намерений. Однако сохраните и затем замените указанный URI обратного вызова прокси-сервера специальным «фальшивым» URI, созданным для легкой идентификации URI фильтром намерений (см. Следующие шаги)
- (Провайдер OAuth) после того, как пользователь завершит авторизацию, перенаправьте браузер на ваш «фальшивый» URI обратного вызова.
- (мобильное веб-приложение) Фильтр намерений обнаруживает «фальшивый» URI обратного вызова и использует этот сигнал для восстановления контроля. Восстановите URI обратного вызова прокси-сервера и используйте Java / HTTP для выполнения запроса.
- (прокси-сервер :: URI обратного вызова) Обменять токен авторизации на токен доступа, а затем сохранить его для будущих вызовов, как раньше
- Выполнять вызовы 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.
- рошлер
