Mapping users from Google Checkout to Android Licensing responses

Question

I am using Android Licensing as described here:

http://developer.android.com/guide/market/licensing/index.html

(...to verify that my customers for my android app have actually payed for the app.) My app has a server component on the web, and for extra safety I'm doing the license validation on this server.

It all works okay. Now, to my problem. Since each new user ties up resources on my central server, I'm actually kind of reluctant to have non-paying users. I have seen some evidence of users continuing to use the app after having gotten a refund (per the normal 15-minute grace period).

To curb this behavior, it would be great if there was some way to map the payment of users at Google Checkout, to actual users in my system. Is this possible?

The ResponseData that I receive from the android license server contains a field called "userId", but this doesn't seem to correspond to any information in Google Checkout. (See http://www.androidadb.com/source/skylight1-read-only/GoogleLVL/src/com/android/vending/licensing/ResponseData.java.html for the definition of ResponseData.)

Is it possible to determine which payment in Checkout maps to which app installation?

Answer 1

As I currently understand it, the userId is obfuscated even on a per-app basis such that you can uniquely identify users per app but not figure which user it is nor whether the same user bought another app.

But I'm not sure you really need to identify these customers based on userId. If you have a server running anyway, the best way to protect your app is to have your server check the licence.

1. App -> Server: Give me a new nonce
2. Server -> App: Here is a secure random nonce
3. App -> Licence Service: Check user licence with this secure random nonce
4. Licence Service -> App: Signed licence response including repetition of nonce
5. App -> Server: Check licence signature with secret key (only on server)
6. Server -> App: Reject, or provide random token for access, etc

In this scenario, you won't authenticate users even if they mess with your LVL checking code.

However, you may of course introduce vulnerabilities after step 6 if you don't watch your step. Still, if you're currently using the standard LVL code and App-side licence check with the secret key stored in your app, changing to a mechanism as sketched above would be a huge improvement (there's even a script to remove standard LVL checking code from apps).