Является ли OAuth на мобильном телефоне, использующим прокси-сервер, слишком большим количеством проблем?
Последние несколько дней я потратил на подготовку и запуск реализации OAuth. Не на Android, а на моем веб-сервере, который будет действовать как прокси для службы, защищенной OAuth. Я как раз собираюсь реализовать свой Android-клиент, но у меня все еще возникают проблемы с безопасностью и реализацией.
OAuth достаточно запутан, когда клиентом является просто веб-браузер. У вас есть следующая последовательность шагов:
- (клиентский веб-браузер) сделать запрос к моему прокси-серверу
- (прокси-сервер) запросить неавторизованный токен от поставщика OAuth (например, API веб-службы)
- (прокси-сервер) спросить Поставщик OAuth, чтобы пользователь авторизовал токен. Перенаправить веб-браузер на URI авторизации поставщика OAuth
- (поставщик OAuth) после того, как пользователь завершит авторизацию, перенаправляет браузер на ваш URI обратного вызова
- (прокси-сервер :: URI обратного вызова) Обменять токен авторизации на токен доступа, а затем сохранить его для будущих вызовов
- Выполнять вызовы API к провайдеру OAuth и возвращать ответный документ клиентскому веб-браузеру
Теперь этого вполне достаточно. Но при использовании того же механизма с мобильным приложением в качестве клиента он становится еще более активным. Проблема, конечно, в том, что вам нужно проделать некоторые акробатические трюки, чтобы внедрить сеанс браузера в поток кода вашего мобильного приложения во время танца OAuth. Это означает, что вам нужно еще больше усложнить танец OAuth следующим образом (я использую приложение для Android в этом примере, чтобы конкретизировать):
- (мобильное веб-приложение :: собственный код) сделать запрос с прокси-сервера с использованием Java / HTTP
- (прокси-сервер) запрашивает неавторизованный токен у поставщика OAuth (например, - API веб-службы)
- (прокси-сервер) возвращает ответный документ в мобильное веб-приложение, который содержит URI перенаправления для авторизации пользователя поставщиком OAuth, предпочтительно скрытый, чтобы скрыть ключ потребителя и другие детали, чтобы предотвратить чрезмерное -air "snooping.
- (мобильное веб-приложение) Запустить действие веб-браузера с URL-адресом авторизации с установленным фильтром намерений. Однако сохраните и затем замените указанный URI обратного вызова прокси-сервера специальным «фальшивым» URI, созданным для простой идентификации URI фильтром намерений (см. Следующие шаги)
- (поставщик OAuth) после того, как пользователь завершит авторизацию, перенаправьте браузер на ваш " фальшивый URI обратного вызова.
- (мобильное веб-приложение) Фильтр намерений обнаруживает «фальшивый» URI обратного вызова и использует этот сигнал для восстановления контроля. Восстановите прокси-сервер ' s URI обратного вызова и использовать Java / HTTP для выполнения запроса.
- (proxy server :: callback URI) Обменять токен авторизации на токен доступа, а затем сохранить его для будущих вызовов, как раньше.
- Выполнять вызовы API к поставщику OAuth и вернуть ответный документ в мобильное веб-приложение
Как видите, это довольно ужасно. Если есть более простой способ сделать это, я очень хочу его услышать. Насколько мне известно, есть только две другие альтернативы, каждая со своими собственными серьезными проблемами.
1) Забудьте о прокси-сервере и делайте все непосредственно из мобильного веб-приложения. Большая дыра в безопасности здесь заключается в том, что вам нужно «запечь» свой ключ клиента и секрет OAuth в своем приложении. Если злоумышленник декомпилирует ваш код и перехватит эти строки, это довольно простая операция для тех, кто имеет опыт обратного проектирования, они могут нанести ущерб вашему приложению и пользователям.
2) Переключитесь на XAuth, где пользователь предоставляет вам свое имя для входа и пароль, и вы «соглашаетесь» не хранить их и обменивать их напрямую на токен доступа с XAuth сервер. Первая проблема - это завоевание доверия пользователей к предоставлению этой информации, проблема, для решения которой был создан OAuth, и, конечно, как насчет людей, которые не соблюдают свое обязательство отказаться от данных для входа? Хуже того, сервер XAuth должен поддерживать XAuth и предлагать соединения HTTPS (SSL), и я видел множество веб-API, которые тоже не поддерживают. Разумеется, соединение SSL необходимо, потому что без него вы бы отправили логин и пароль пользователя по сети в виде простого текста при выполнении запроса XAuth.
http://developer.android .com / reference / android / webkit / CacheManager.html
В заключение, я Я хотел бы услышать мысли тех, кто боролся с этими же проблемами при создании своих приложений OAuth.
- roschler