Эффективный OAuth для API Google с телефона Android - PullRequest
1 голос
/ 20 июня 2011

Я пытаюсь получить авторизацию для Google Buzz, Контакты из приложения Android.Процесс похож на этот.

  • Пользователь выбирает, хочет ли он использовать Buzz.
  • Используя OAuth / Client Auth, нам нужно получить одноразовый код авторизации.
  • Этот код будет использоваться веб-службой для периодического чтения каналов Buzz.

Теперь проблема заключается в том, как получить код авторизации (не временный токен) из приложения Androidи отправьте его в веб-сервис.Я мог бы использовать обычный OAuth2.0 и использовать мой веб-сервис в качестве URL перенаправления для получения кода.Но в таком случае, как я могу сообщить веб-службе, что код принадлежит какому пользователю?Могу ли я передать дополнительную информацию с танцем OAuth?

1 Ответ

1 голос
/ 21 июня 2011

Я настоятельно рекомендую использовать OAuth 2. Поток намного лучше для конечного пользователя, и намного проще реализовать нечто подобное.Кроме того, он использует токены на предъявителя, что означает, что вы можете поддерживать свою сторону сервера обновлений токенов там, где она действительно безопасна, и отправлять токены доступа на Android только тогда, когда они необходимы.

Недостатком этого подхода является то, что эффективнокаждый раз, когда ваше приложение загружается, ему нужно позвонить домой, чтобы получить последний токен доступа.Но, получив этот токен доступа, он может делать любые вызовы API, которые ему необходимы, непосредственно в API Buzz и Contacts.

Однако для этого вам не нужно передавать дополнительную информацию с помощью танца OAuth.Вместо этого вашему Android-приложению необходимо уже точно определить, какой пользователь выполнил вход в ваше приложение, а затем убедиться, что сервер только отправляет обратно маркеры доступа, связанные с аутентифицированным пользователем.Если у него нет обновленного токена доступа для этого пользователя, ему необходимо отправить запрос на сервер авторизации Google, чтобы получить последний токен доступа, а затем передать его клиенту.Так что, безусловно, есть большой потенциал для некоторой задержки, потому что это, как правило, синхронный вызов, но обычно это небольшая цена за преимущества, которые дает OAuth 2 по сравнению с OAuth 1.

...