Я просто отправил ответ к подобному вопросу о StackOverflow.

Google называет это Гибридные приложения и объясняет, как "приложение для Android получает офлайновый доступ для веб-бэкенда" .

суть его - то, что необходимо будет передать массажировавший scope строка в GoogleAuthUtil.getToken, чтобы заставить это возвращать Код авторизации (не Маркер OAuth2). Тот Код авторизации может передаваться с Вашего мобильного приложения на Ваш сервер и обмениваться для Маркера Маркера и Обновления OAuth2, согласно это схематичное .

scope параметр должен выглядеть примерно так:

oauth2:server:client_id:<your_server_client_it>:api_scope:<scope_url_1> <scope_url_2> ...

Можно использовать маркер доступа, полученный мобильным приложением где-либо еще. SDK диска имеет хорошее и простое введение, которое проходит поток на https://developers.google.com/drive/quickstart-android

По крайней мере, с Google, маркер доступа в конечном счете истекает. Поэтому андроид AccountManager имеет invalidateAuthToken метод - кэшируемый маркер доступа истек, и необходимо сказать AccountManager прекращать давать Вам старый и вместо этого получать новый. Это делает несколько более безопасным кэшировать маркер, поскольку сам маркер не предоставляет Вам вечный доступ как того пользователя. Вместо этого когда допустимый, это просто говорит "в какой-то момент в недалеком прошлом, этот маркер был получен надежным источником".

Вот несколько вещей, которые я нашел полезными при работе с маркерами. Первой является tokeninfo конечная точка Google. Сам маркер просто base64-кодируется JSON. Это означает, что не шифруется, таким образом, несомненно, необходимо использовать HTTPS для коммуникации. Однако это также означает, что можно исследовать маркер и иметь лучшую идею того, что продолжается.

https://www.googleapis.com/oauth2/v1/tokeninfo? id_token =

, Если бы Ваш маркер был "abcdef", Вы перешли бы к:

https://www.googleapis.com/oauth2/v1/tokeninfo? id_token=abcdef

и Google распаковали бы маркер для Вас. Это - простой объект JSON, который включает "expires_in" поле, говоря Вам число секунд, в течение которых маркер все еще допустим. В 6:03 в видео ниже Вас видят распакованный маркер:

https://developers.google.com/events/io/sessions/383266187

, Что видео включает полный обзор OAuth2 и определенно стоит посмотреть в целом, если Вы собираетесь быть контактом с OAuth и маркерами. Докладчик также обсуждает другие формы маркеров Oauth2, которые не являются маркерами доступа, которые не истекают.

Другой полезный ресурс является Детской площадкой OAuth. Это позволяет Вам сделать основные вещи как объемы запроса, составить запросы и возвратить маркеры. Эта ссылка, кажется, работает эпизодически, и на Chrome я должен был установить приложение Детской площадки OAuth:

https://developers.google.com/oauthplayground /

И вот является учебным руководством Tim Bray, докладчика в видео, объясняя, как использовать маркеры доступа для передачи с сервером из приложения для Android. Это было полезно для меня, потому что я начал понимать, как разные вещи в Google API Console сотрудничают:

http://android-developers.blogspot.in/2013/01/verifying-back-end-calls-from-android.html

Относительно фактического ответа на Ваш вопрос, я сказал бы, что Вы никогда не должны кэшировать маркер доступа на сервере. Как объяснено в Вызовах Бэкэнда Проверки из ссылки Android выше, проверяя маркер почти всегда быстрый статический вызов, означая, что нет никакой причины кэшировать маркеры:

библиотеки могут кэшировать сертификаты Google и только обновить их при необходимости, таким образом, проверка является (почти всегда) быстрым статическим вызовом.

Наконец, можно действительно использовать AccountManager для получения маркеров доступа. Однако Google теперь вместо этого поощряет использование GoogleAuthUtil класс в библиотеке Play Services вместо этого:

Вкратце what' s различие от использования OAuth2 запрашивают, чтобы getAuthToken и getToken

Здесь отметили комментарий Tim Bray, того же парня все снова и снова из вышеупомянутых ссылок, говоря, что они прикладывают свои усилия к эти GoogleAuthUtil маршрут. Обратите внимание, однако, что это означает, что Вы были бы ограничены аутентификацией Google. Я полагаю, что эти AccountManager мог использоваться для получения, например, маркера Facebook вместо этого - не случай с GoogleAuthUtil.

это описывает точно, что Вы хотите: https://developers.google.com/identity/protocols/CrossClientAuth

Когда у нас была потребность сделать что-то подобное на non-google OAuth Server, мы сохранили маркеры в DB на веб-сайте. Приложение затем использовало бы веб-сервисы, чтобы запросить маркер при необходимости запросить данные.

пользователь мог сделать регистрацию OAuth или в сети или в приложении. Они совместно использовали тот же маркер приложения, таким образом, они могли совместно использовать тот же маркер доступа. После регистрации мы сохранили бы доступ и маркеры обновления в DB для использования от того, какой бы ни для приложения был нужен он.