API authentication using Google OAuth 2.0

Question

I would like to develop a REST API that will be accessed from an android application, but I need to authorize the users of the client-side application. A simple solution to this would be to ask the user to register to my service and then use that username/password to make successful calls to the REST API. However, I would prefer to stick with the state-of-the-art technologies, which seem to combine convenience in registration and better security. So, I decided to integrate with Google OpenID or OAuth 2.0 for the user authentication and authorization. I know the difference of these two terms and corresponding rechnologies, but I also found out that the authentication using OAuth 2.0 includes authorization steps.

I have done a lot of research before posting here, which directed me to a non standard solution that I will present you here. Some background about my case: The Rest API will be providing some application specific data, which will be available to the mobile app user, but the user of the app will need to be uniquely identified and be limited to certain number of calls.

Using the Google Account linked to the android app user appeared as the greatest option for easy integration with the authentication mechanism. However, the client won't be accessing Google APIs but our own REST API, while the REST API doesn't need to make any calls to the Google APIs. But using the AccountManager of the Android SDK, I noticed that I could use the oauth access_token of the linked google account and send it to the REST API, and finally use a TokenInfo validation API to check the validity of the token. This way I could reuse the authentication of Google account for authorizing and authenticating access to my REST API.

If this sounds non standard, or you think that it somehow goes against the rules/purpose of the OAuth 2.0 protocol, could you direct me to proper use that protocol to cover my requirements for authenticating users on my REST API using Google Authentication?

Answer 1

I'm looking at the same problem. So far, I haven't found any reasonable way to do it :(

The solution you managed to get it working (use AccountManager to get a token, send that token -securely- to your backend and then use this token for validating with the userinfo service, to check that the email is validated) has one flaw: it's restricted to the anonymous quota. Your backend is not using a client_id and client_secret when querying the userinfo service, and you may run out of quota very soon.

You may register your app in the API Console to obtain a client_id and client_secret, but they won't match those used to obtain the token by the Account Manager.

Google Play Services simplified the development process and UI experience for the user, but they still issue a token that is not valid to transfer to your backend for validation. In this case, the token is obtained using your development key signature, so it's only valid for your application. It is equivalent to the client_id or client_secret, but I don't know if there's a way to somehow replicate this parameters in the server (provided that the server could have access to the same key used to sign Android's app).

I'm thinking of two other possible solutions:

• Use the web server flow at the app. This has one clear drawback: you need to embbed a web site in the app, and the user experience is far from ideal. But it should work.
• Use a Google App Engine app or Google Cloud Endpoint as an entry to your backend, and then connect as you wish to your real backend.

Any other thoughts or ideas would be greatly appreciated.

Answer 2

Generally, OpenID is used for authentication and OAuth for authorization to a user's resources with implied authentication and express consent.

OAuth authorizes your app -- your REST API -- to retrieve certain information from the user's profile within Google. Even if you do not retrieve any detailed attributes of the user's profile, the very presence of an account in Google is still information that you can use to establish unique identities within your app. So, you are not going against any 'rules' or 'purpose' of the OAuth 2.0 protocol.

If your android app can access the Google account on the device and utilize the OAuth API, it should work for you. If you choose not to use the token to access any further information from the user's profile in Google, you are not using further information, that is your choice. However, if you want to retrieve further information, you would need to set a scope and obtain the user's consent.

In summary, your approach would work and you would be using OAuth in a limited way.