Как я могу проверить аутентификацию Google маркер доступа API?

я должен так или иначе запросить Google и спросить: действительно ли этот маркер доступа допустим для example@example.com?

номер все, в чем Вы нуждаетесь, является входом в систему стандарта запроса с Федеративный Вход в систему для Google Account Users от Вашего домена API. И только после этого Вы могли сравнить "персистентный идентификатор пользователя", с одним Вы имеете от 'открытого интерфейса'.

значение области используется на Странице входа в систему Google Federated для идентификации сайта запроса пользователю. Это также используется для определения значения персистентного идентификатора пользователя, возвращенного Google.

, Таким образом, Вы должны быть от того же домена как 'открытый интерфейс'.

И не забывают, что пользователь должен быть уверен, что Вашему API можно было доверять ;) Таким образом, Google спросит пользователя, если он позволит Вам проверять на его идентификационные данные.

Попытайтесь выполнить аутентифицируемый в OAuth запрос с помощью маркера для https://www.google.com/accounts/AuthSubTokenInfo. Это только документируется для работы на AuthSub, но он работает на OAuth также. Это не скажет Вам, для какого пользователя маркер, но это скажет Вам, для каких сервисов это допустимо, и запрос перестанет работать, если маркер будет недопустим или будет отменен.

Google никогда не мог отвечать на Ваш вопрос, потому что это не "действительно ли этот маркер доступа, допустимо?" Это - token+secret.

An arbitrary OAuth access token can't be used for authentication, because the meaning of the token is outside of the OAuth Core spec. It could be intended for a single use or narrow expiration window, or it could provide access which the user doesn't want to give. It's also opaque, and the OAuth consumer which obtained it might never have seen any type of user identifier.

An OAuth service provider and one or more consumers could easily use OAuth to provide a verifiable authentication token, and there are proposals and ideas to do this out there, but an arbitrary service provider speaking only OAuth Core can't provide this without other co-ordination with a consumer. The Google-specific AuthSubTokenInfo REST method, along with the user's identifier, is close, but it isn't suitable, either, since it could invalidate the token, or the token could be expired.

If your Google ID is an OpenId identifier, and your 'public interface' is either a web app or can call up the user's browser, then you should probably use Google's OpenID OP.

OpenID consists of just sending the user to the OP and getting a signed assertion back. The interaction is solely for the benefit of the RP. There is no long-lived token or other user-specific handle which could be used to indicate that a RP has successfully authenticated a user with an OP.

One way to verify a previous authentication against an OpenID identifier is to just perform authentication again, assuming the same user-agent is being used. The OP should be able to return a positive assertion without user interaction (by verifying a cookie or client cert, for example). The OP is free to require another user interaction, and probably will if the authentication request is coming from another domain (my OP gives me the option to re-authenticate this particular RP without interacting in the future). And in Google's case, the UI that the user went through to get the OAuth token might not use the same session identifier, so the user will have to re-authenticate. But in any case, you'll be able to assert the identity.