Question

The Story: I am making an Android app that allows a user to purchase a subscription, and does not require the user to have an account or login. I want to check whether or not a user has purchased a subscription, and the Google Play Android Developer API seems to provide this service.

The Problem (TL;DR): Should I use OAuth as a “web application”, “installed application”, “service application”, or none of the above?

The Problem: To get started with this, I am told:

Access to the Google Play Android Developer API is authenticated using
the OAuth 2.0 Web Server flow. Before you can use the API, you will
need to set up an APIs Console project, create a client ID and
generate a refresh token. -source

Fair enough. There are then setup instructions that go on to say:

On the second page, select web application and set the redirect URI
and Javascript origins.

My application does access the Internet, but it is an installed Android app, not a web application, so I don’t have a “redirect URI” or “Javascript origins” to link it to. Additionally, this would require a user to log in, which I do not want and is not necessary in my case (I just want to check whether or not the user has purchased a subscription).

So if instead of a “web application” I try to create an “installed application (Android)”, this still requires a user login, to be able to manage the user’s resources.

I do not want this. There is a third alternative called a “service account” that does not require a user login:

A Service Account is used when you have a service that wants to handle
its “own” resources (e.g., an App Engine app that manages Compute
Engine resources), as opposed to the resources of an external user
(e.g., the standard OAuth flow). Using a Service Account the app will
be the owner of the resources… If you use a Service Account, you will only get data about the service’s purchases. -source

I’m not sure if that is what I want in my case…

Finally, there is also this option:

The simplest flow is one where no end-user authorization is needed.
You still need to identify your client application using the API key. -source

This seems perfect! However, I was told initially that to use the Google Play Android Developer API I need to authenticate with OAuth 2.0, and this does not use a client ID which I was initially told that I specifically need.

Answer 1

There are at least 2 problems with what you are trying to achieve here:

1. As you would be handling the server response in your Android application, you would have something like this in your code:

   if (isSubscriptionValid())
   

   Somebody could tamper with your application’s APK on his device (which is very easy) and simply replace that check with:

   if (true)
   

   The attacker would then have access to your content without ever being subscribed.

2. As calls to the API have to be authorized by your developer account and being personally logged in on each users device is obviously no option, you would have to go for Service Accounts, as you’ve already figured out correctly.

   These however are only meant for server-to-server interactions, as otherwise it would require you to store your private key on everybodys device and as it is not possible to store data securely on an Android device, you wouldn’t meet this requirement:

   The private key must be stored and managed securely.

Google recommends you to have a backend server to do this kind of checks. So you can decide if a subscription is valid before handing over content to the client and other things:

The API is designed to be used from your backend servers as a way of securely managing subscriptions, as well as extending and integrating subscriptions with other services.

If you do not have a backend server available, you have to rely on In-app Billing Notifications.