Menambahkan Verifikasi Lisensi Sisi Server ke Aplikasi Anda
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Saat melakukan verifikasi bahwa pengguna telah membeli atau mendownload salinan sah aplikasi Anda dari Google Play Store, sebaiknya jalankan pemeriksaan verifikasi lisensi di server yang Anda kontrol.
Panduan ini menunjukkan proses langkah demi langkah untuk menyelesaikan verifikasi lisensi sisi server dan beberapa praktik terbaik terkait dengan pelaksanaan pemeriksaan ini.
Ringkasan proses
Gambar 1 menunjukkan bagaimana informasi ditransfer antara aplikasi, Google Play, dan server pribadi Anda:
Gambar 1. Alur data antara aplikasi Anda dan Google Play, lalu antara aplikasi dan server pribadi Anda
Aplikasi Anda membuat permintaan kepada Google Play, yang menanyakan apakah pengguna tertentu telah membeli atau mendownload salinan sah aplikasi Anda.
Google Play merespons dengan mengirimkan objek data respons, yaitu objek berjenis ResponseData, ke aplikasi Anda. Objek ini adalah bagian informasi yang ditandatangani, yang menyatakan apakah pengguna telah membeli atau mendownload salinan sah aplikasi Anda.
Aplikasi Anda membuat permintaan ke server pribadi yang Anda kontrol, yang memverifikasi konten data respons tersebut.
Server akan merespons dengan mengirimkan status ke aplikasi Anda, yang mengindikasikan apakah pengguna memang telah membeli atau mendownload salinan sah aplikasi Anda. Jika server memberikan pesan "berhasil", verifikasi respons tersebut, lalu berikan akses kepada pengguna ke resource yang memerlukan lisensi.
Karena data respons ditandatangani oleh Google Play, lalu diperiksa di server Anda, tidak ada cara untuk mengubah objek pada perangkat yang sedang menjalankan aplikasi Anda. Jika aplikasi mengandalkan server dan menyediakan resource hanya untuk pengguna yang sah, aplikasi akan jauh lebih terlindungi dari pengguna yang tidak sah.
Bagian berikut menyediakan pertimbangan tambahan yang perlu diingat saat menjalankan verifikasi lisensi sisi-server.
Mengamankan dari serangan replay
Setelah menerima respons dari Google Play terkait status lisensi pengguna, hal ini memungkinkan pengguna untuk menyalin data respons dan menggunakannya beberapa kali, atau memberikannya kepada pengguna lain yang kemudian dapat memalsukan permintaan mereka sendiri ke server pribadi aplikasi Anda. Tindakan semacam ini dikenal sebagai serangan replay.
Untuk mengurangi kemungkinan pengguna berhasil melakukan serangan replay, lakukan langkah berikut sebelum mengirim permintaan ke server aplikasi Anda:
Periksa stempel waktu yang disertakan dalam data respons, pastikan bahwa Google Play menghasilkan respons baru-baru ini.
Lakukan pembatasan kapasitas pada permintaan server Anda, seperti backoff eksponensial, untuk mengurangi frekuensi aplikasi Anda mencoba mengirimkan data respons yang sama ke server aplikasi Anda.
Sebelum memverifikasi konten data respons Google Play di server pribadi, buatlah permintaan awal berbasis autentikasi ke server pribadi Anda. Dalam permintaan pertama ini, kirim kredensial pengguna ke server Anda, kemudian minta server Anda merespons dengan nonce, atau nomor yang hanya digunakan sekali. Kemudian, Anda dapat menyertakan nonce ini di permintaan Anda berikutnya ke server pribadi, untuk meminta data verifikasi lisensi. Untuk detail mengenai petunjuk memilih nilai yang baik untuk nonce, lihat bagian membuat nilai nonce yang sesuai.
Membuat nilai nonce yang sesuai
Gunakan salah satu dari teknik berikut untuk membuat nilai nonce yang sulit ditebak:
Buat nilai hash berdasarkan ID pengguna.
Buat nilai acak per pengguna. Simpan nilai acak ini di server aplikasi Anda sebagai bagian dari atribut yang diberikan pengguna.
Memverifikasi data respons dari server Anda
Saat meninjau data respons yang dikirimkan oleh server aplikasi ke aplikasi Anda, pastikan bahwa respons License Verification Library tidak dipalsukan. Verifikasi tanda tangan yang disertakan dalam data respons server aplikasi dengan membandingkannya dengan kunci yang diterima oleh aplikasi Anda dari Google Play di langkah sebelumnya.
Perlu diingat juga bahwa pemblokiran khusus untuk License Verification Library (LVL) adalah satu-satunya bagian yang perlu ditandatangani. Oleh karena itu, pemblokiran merupakan satu-satunya bagian dari data respons server aplikasi Anda yang harus dipercaya oleh aplikasi Anda.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-27 UTC."],[],[],null,["# Adding Server-Side License Verification to Your App\n\nWhen verifying that the user has purchased or downloaded a legitimate copy of\nyour app from the Google Play Store, it's best to perform the license\nverification check on a server that you control.\n\nThis guide presents a step-by-step process for completing server-side license\nverification and presents some best practices related to performing this check.\n\nProcess overview\n----------------\n\nFigure 1 shows how information is transferred between your app, Google Play, and\nyour private server: \n**Figure 1.** Flow of data between your app and Google Play, then between your app and your private server\n\n1. Your app makes a request to Google Play, inquiring about whether a particular user has purchased or downloaded a legitimate copy of your app.\n2. Google Play responds by sending a *response data object* , an object of type [`ResponseData`](/google/play/licensing/licensing-reference#lvl-summary), to your app. This object is a signed piece of information that states whether the user has purchased or downloaded a legitimate copy of your app.\n3. Your app makes a request to a private server that you control, verifying the contents of the response data.\n4. The server responds by sending a status to your app, indicating whether the user has indeed purchased or downloaded a legitimate copy of your app. If the server provides a \"success\" message, [verify the\n response](#verify-app-server-response) and then grant the user access to the resources that require a license.\n\nBecause the response data is signed by Google Play, then checked on your\nserver, there's no way to modify the object on the device running your app. If\nyour app relies on the server and makes resources available only to legitimate\nusers, your app is substantially more protected against unauthorized users.\n\nThe following sections provide additional considerations to keep in mind when\nperforming server-side license verification.\n\nSafeguard against replay attacks\n--------------------------------\n\nAfter receiving a response from Google Play regarding the user's license status,\nit's possible for the user to copy the response data and use it multiple times,\nor give it to other users who could then forge their own requests to your app's\nprivate server. This sort of action is known as a *replay attack*.\n\nTo reduce the likelihood of users performing replay attacks successfully, take\nthe following measures before sending a request to your app's server:\n\n- Check the timestamp that's included in the response data, making sure that\n Google Play generated the response recently.\n\n | **Note:** You can increase the allowed difference between the response data's timestamp and the current time based on how long users should be able to interact with license-bound resources after they deactivate their license.\n- Perform rate-limiting on your server request, such as exponential backoff, to\n reduce the number of times that your app attempts to send the same response data\n to your app's server.\n\n | **Caution:** To preserve a good user experience in cases where a user interacts with your app on a variety of devices, be careful if you add rate-limiting based on number of devices.\n- Before verifying the contents of Google Play's response data on your private\n server, make an initial, authentication-based request to your private server. In\n this first request, send user credentials to your server, and have your server\n then respond with a *nonce* , or a number that is used only once. You can then\n include this nonce in your next request to your private server, asking for\n license verification data. For details on how to choose a good value for the\n nonce, see the [generate a suitable nonce value](#generate-nonce) section.\n\n | **Note:** Include a user ID field in both the nonce request and the license verification request. Your app's server can then compare the fields' values from the two requests and make sure they match.\n\n### Generate a suitable nonce value\n\nUse one of the following techniques to create a nonce value that's difficult to\nguess:\n\n- Generate a hash value based on the user's ID.\n- Generate a random value on a per-user basis. Store this random value on your app's server as part of a given user's attributes.\n\nVerify response data from your server\n-------------------------------------\n\nWhen reviewing response data that your app's server sends to your app, make sure\nthat the License Verification Library response isn't forged. Verify the\nsignature that's included in the app server's response data by comparing it\nwith the key that your app received from Google Play in a previous step.\n\nIt's also worth remembering that the block specific to the License Verification\nLibrary (LVL) is the only part that's signed. Therefore, it's the only part of\nyour app server's response data that your app should trust."]]
