Validate server-side verification (SSV) callbacks

Page Summary

outlined_flag

• Server-side verification callbacks notify an external system to reward a user for interacting with a rewarded ad, offering increased protection against spoofing compared to client-side methods.

• This guide demonstrates verifying rewarded SSV callbacks using the Tink Java Apps library, though any third-party library supporting ECDSA can be used.

• Rewarded SSV callbacks include various query parameters providing details about the ad interaction, including the ad unit, reward amount, and transaction ID.

• Public keys required for verification can be fetched from the AdMob key server and should be cached but not for longer than 24 hours due to regular rotation.

• The verification process involves parsing the callback URL to get the content to be verified, the signature, and the key ID, then using the appropriate public key to verify the signature against the content.

Server-side verification callbacks are URL requests, with query parameters expanded by Google, that are sent by Google to an external system to notify it that a user should be rewarded for interacting with a rewarded or rewarded interstitial ad. Rewarded SSV (server-side verification) callbacks provide an extra layer of protection against spoofing of client-side callbacks to reward users.

This guide shows you how to verify rewarded SSV callbacks by using the Tink Java Apps third-party cryptographic library to ensure that the query parameters in the callback are legitimate values. Although Tink is used for the purposes of this guide, you have the option to use any third-party library that supports ECDSA. You can also test your server with the testing tool in the AdMob UI.

Prerequisites

• Enable rewarded server-side verification on your ad unit.

Use RewardedAdsVerifier from the Tink Java Apps library

The Tink Java Apps GitHub repository includes a RewardedAdsVerifier helper class to reduce the code required to verify a rewarded SSV callback. Using this class enables you to verify a callback URL with the following code.

RewardedAdsVerifier verifier = new RewardedAdsVerifier.Builder()
    .fetchVerifyingPublicKeysWith(
        RewardedAdsVerifier.KEYS_DOWNLOADER_INSTANCE_PROD)
    .build();
String rewardUrl = ...;
verifier.verify(rewardUrl);

If the verify() method executes without raising an exception, the callback URL was successfully verified. The Rewarding the user section details best practices regarding when users should be rewarded. For a breakdown of the steps performed by this class to verify rewarded SSV callbacks, you can read through the Manual verification of rewarded SSV section.

SSV callback parameters

Server-side verification callbacks contain query parameters that describe the rewarded ad interaction. Parameter names, descriptions, and example values are listed below. Parameters are sent in alphabetical order.

Ad source identifiers

Rewarding the user

It is important to balance user experience and reward validation when deciding when to reward a user. Server-side callbacks may experience delays before reaching external systems. Therefore, the recommended best practice is to use the client-side callback to reward the user immediately, while performing validation on all rewards upon the receipt of server-side callbacks. This approach provides a good user experience while ensuring the validity of granted rewards.

However, for applications where reward validity is critical (for example, the reward affects your app's in-game economy) and delays in granting rewards are acceptable, waiting for the verified server-side callback may be the best approach.

Custom data

Apps that require extra data in server-side verification callbacks should use the custom data feature of rewarded ads. Any string value set on a rewarded ad object is passed to the custom_data query parameter of the SSV callback. If no custom data value is set, the custom_data query parameter value won't be present in the SSV callback.

The following code sample demonstrates how to set custom data on a rewarded ad object before requesting an ad.

  firebase::gma::RewardedAd* rewarded_ad;
  rewarded_ad = new firebase::gma::RewardedAd();

  firebase::gma::RewardedAd::ServerSideVerificationOptions options;
  options.custom_data = "SAMPLE_CUSTOM_DATA_STRING";
  rewarded_ad->SetServerSideVerificationOptions(options);

If you want to set the custom reward string, you must do so before showing the ad.

Manual verification of rewarded SSV

The steps performed by the RewardedAdsVerifier class to verify a rewarded SSV are outlined below. Although the included code snippets are in Java and leverage the Tink third-party library, these steps can be implemented by you in the language of your choice, using any third-party library that supports ECDSA.

Fetch public keys

To verify a rewarded SSV callback, you need a public key provided by AdMob.

A list of public keys to be used to validate the rewarded SSV callbacks can be fetched from the AdMob key server. The list of public keys is provided as a JSON representation with a format similar to the following:

{
 "keys": [
    {
      keyId: 1916455855,
      pem: "-----BEGIN PUBLIC KEY-----\nMF...YTPcw==\n-----END PUBLIC KEY-----"
      base64: "MFkwEwYHKoZIzj0CAQYI...ltS4nzc9yjmhgVQOlmSS6unqvN9t8sqajRTPcw=="
    },
    {
      keyId: 3901585526,
      pem: "-----BEGIN PUBLIC KEY-----\nMF...aDUsw==\n-----END PUBLIC KEY-----"
      base64: "MFYwEAYHKoZIzj0CAQYF...4akdWbWDCUrMMGIV27/3/e7UuKSEonjGvaDUsw=="
    },
  ],
}

To retrieve the public keys, connect to the AdMob key server and download the keys. The following code accomplishes this task and saves the JSON representation of the keys to the data variable.

String url = ...;
NetHttpTransport httpTransport = new NetHttpTransport.Builder().build();
HttpRequest httpRequest =
    httpTransport.createRequestFactory().buildGetRequest(new GenericUrl(url));
HttpResponse httpResponse = httpRequest.execute();
if (httpResponse.getStatusCode() != HttpStatusCodes.STATUS_CODE_OK) {
  throw new IOException("Unexpected status code = " + httpResponse.getStatusCode());
}
String data;
InputStream contentStream = httpResponse.getContent();
try {
  InputStreamReader reader = new InputStreamReader(contentStream, UTF_8);
  data = readerToString(reader);
} finally {
  contentStream.close();
}

Note that public keys are regularly rotated. You will receive an email to inform you of an upcoming rotation. If you're caching public keys, you should update the keys upon receiving this email.

Once the public keys have been fetched, they must be parsed. The parsePublicKeysJson method below takes a JSON string, such as the example above, as input, and creates a mapping from key_id values to public keys, which are encapsulated as ECPublicKey objects from the Tink library.

private static Map<Integer, ECPublicKey> parsePublicKeysJson(String publicKeysJson)
    throws GeneralSecurityException {
  Map<Integer, ECPublicKey> publicKeys =