User Identity
Definition
Implementing user identity is an important aspect for uniquely identifying users within your application. Transactions are associated with users in order to verify their uniqueness, but also to ensure users can retrieve and restore their own purchases later. User Inventory does not work without it. It is therefore necessary to provide an user identifier with every API call, so all purchases are being tracked with the correct user.
If an user ID is not provided with the call to receipt validation, the server generates and responds with a (v4 UUID) user identifier.
Example: 3ed5e911-5eaa-46b3-8efc-74612d2b878d
When the server responded with a newly generated user identifier, you will want to save the ID on the device locally, or persist it in the platform native key-value storage.
Authentication
Adding native or third-party authentication to your application allows users to log in, stop and resume on a different device where they left off, or even sharing purchases and subscriptions across any other platform. This is because your authentication system would return the same user identifier for the same set of user credentials. If users delete and reinstall your application, this way they would not require going through the restore workflow.
Please note that, due to the many different platforms, programming languages and SDKs, the Receipt Validator service does not ship with an authentication system. It is your decision to use one of the SDKs that meets your needs, your enterprise or custom solution and pass the returned user identifier over to the API.
Although it should definitely be implemented, an authentication system is not strictly required in order to use our Receipt Validator service!
When not having an authentication system, you could use the server-generated user identifier as mentioned above, along with the User Behaviour setting on your application set to Alias. Since deleting and reinstalling your application would potentially wipe the local user identifier, users are able to invoke the native restore workflow for validating their receipts again. By sending the same receipt with a new user identifier, they would be aliased with the original user, supporting up to 5 alias users in total. This means your users are allowed to reinstall your application or switch devices up to 5 times, before their purchase would be blocked, requiring further contact with support.
User Behaviour
Remember that your selection of User Behaviour in the App Setup section comes with some requirements regarding authentication and massively impacts the security on how users are associated with transactions:
| Mode | Description |
|---|---|
Alias | Minimum security. Can be used with device-generated user identifiers and multiple different devices or installs just by sending the same receipt via restore again. |
Transfer | Normal security. Theoretically there should only be one user per transaction, but it can be claimed by a different user or account e.g. when switching devices after a certain cooldown period. |
Block | Highest security. Only one specific user can ever access a specific purchase. Requires an authentication system where users can also claim back their login credentials. |
Best practices
When it comes to best practices for user authentication and security, consider the following points:
- Do not use emails or other forms of personal data as user IDs for privacy reasons
- In general, user IDs should not be guessable and include some randomization
- Do not use device identifiers such as IDFA or Ad-ID since they are not unique
- Do not hardcode user IDs into your application since all users would then be the same
It is best practice to require users to log in before making purchases and authenticating them with a native provider, such as 'Play Games Services', 'Sign in with Apple' or when taking a more high-level approach, PlayFab login services. For cross-platform authentication, services like 'Facebook Login' could be used. The login should be incentivised by explaining users the advantages of cloud-saved inventory and cross-platform support.
Restrictions
The maximum length of user identifiers is 100 characters. Additionally, an app user identifier should not contain or be equal to the following strings: (empty string), null, voided.