Como adicionar a verificação de licenças do lado do servidor ao app
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Para confirmar a compra ou o download de uma cópia legítima do
seu app na Google Play Store, é melhor realizar a verificação da licença
em um servidor controlado por você.
Este guia apresenta um processo passo a passo para a verificação da licença do lado do servidor e algumas práticas recomendadas relacionadas a essa verificação.
Visão geral do processo
A Figura 1 mostra como as informações são transferidas entre seu app, o Google Play e seu servidor particular:
Figura 1. Fluxo de dados entre o app e o Google Play e, em seguida, entre o app e o servidor particular.
Seu app consulta o Google Play sobre a
compra ou o download de uma cópia legítima dele feita por um determinado usuário.
O Google Play responde enviando um objeto de dados de resposta, um objeto do tipo
ResponseData, para
o app. Esse objeto é uma informação assinada que informa se o
usuário comprou ou fez o download de uma cópia legítima do app.
Seu app faz uma solicitação a um servidor particular controlado por você, verificando o
conteúdo dos dados de resposta.
O servidor responde enviando um status para o app, indicando se o
usuário realmente comprou ou fez o download de uma cópia legítima. Se o
servidor enviar a mensagem "sucess", verifique a
resposta e, então, conceda ao usuário acesso aos
recursos que exigem uma licença.
Como os dados de resposta são assinados pelo Google Play e verificados no seu servidor, não é possível modificar o objeto no dispositivo que executa o app. Se o app depender do servidor e disponibilizar recursos apenas para usuários legítimos, ele ficará substancialmente mais protegido contra usuários não autorizados.
As seções a seguir oferecem outras considerações para a verificação da licença do servidor.
Proteger contra ataques de repetição
Depois de receber uma resposta do Google Play sobre o status da licença, o usuário pode copiar os dados de resposta e usá-los várias vezes ou fornecê-los a outros usuários, que podem fazer as próprias solicitações ao servidor particular do seu app. Esse tipo de ação é conhecido como ataque de repetição.
Para reduzir a probabilidade de usuários realizarem ataques de repetição, tome as seguintes medidas antes de enviar uma solicitação para o servidor do app:
Verifique no carimbo de data/hora incluído nos dados de resposta para garantir que o Google Play gerou a resposta recentemente.
Faça a limitação de taxa na solicitação do servidor, como espera exponencial, para reduzir o número de vezes que o app tenta enviar os mesmos dados de resposta ao servidor.
Antes de verificar o conteúdo dos dados de resposta do Google Play no seu servidor
particular, envie a ele uma solicitação inicial baseada em autenticação. Nessa primeira solicitação, envie credenciais de usuário para o servidor e faça com que ele responda com um valor de uso único, ou seja, um número que possa ser usado apenas uma vez. Em seguida, você pode incluir esse valor na próxima solicitação para o servidor particular, solicitando dados de verificação de licença. Para saber mais sobre como escolher um bom valor de uso único, consulte a seção Gerar um valor de uso único adequado.
Gerar um valor de uso único adequado
Use uma das técnicas a seguir para criar um valor de uso único difícil de adivinhar:
Gere um valor hash com base no ID do usuário.
Gere um valor aleatório por usuário. Armazene esse valor aleatório no servidor do app como parte dos atributos de um determinado usuário.
Verificar dados de resposta do servidor
Ao analisar os dados de resposta enviados pelo servidor do app, verifique se a resposta da License Verification Library não foi forjada. Verifique a assinatura incluída nos dados de resposta do servidor do app comparando-a com a chave que o app recebeu do Google Play em uma etapa anterior.
Vale lembrar também que o bloco específico da License Verification Library (LVL, na sigla em inglês) é a única parte assinada. Portanto, é a única parte confiável dos dados de resposta do servidor.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
