Authenticating Google Wallet for Digital Goods postbacks

Question

Making sure a purchase with Google Wallet for Digital Goods has been effectively paid out by the customer rely on an out-of-band postback from Google server to the merchant server. Apparently the only parameter sent by Google server at this time is the original JWT token that as been originally sent to the client, with an additional order ID. This JWT token is known to any customer.

How can you make sure this postback is originating from Google?

I may miss something, but if the merchant server use a simple URL (such as postback.domain.com) it's easy for an attacker to guess it by polling, and then issue a false payment confirmation call with the original JWT token, plus a dummy order ID. For me the merchant server has no way to make sure the postback is valid or not. Using a callback URL with some embedded key seems a poor workaround in term of security.

It's rather strange, as it should have been easy to include in the postback a simple signature. For example a hash based on the JWT token content, the merchant account private shared key, and a new random sequence generated by the merchant server, included in the initial JWT token. This hash can be computed only by Google and the merchant, and could have been used to check the authenticity of the postback.

Answer 1

JWT includes the hash you are referring to - it's the 3rd segment. You need to verify the postback JWT using your seller secret.

The iat and exp fields (issued at, expiration, respectively) help you with replay issues and the "random sequence" (though not really "random") you are also referring to...

Hth....