User recognition offers a safe way of identifying and authenticating users across web services and applications. Currently, the platform supports the following algorithms and encryptions:
Algorithm type | Supported algorithms |
JWT based |
|
JWS (JSON Web Signature) | HS256, HS384, HS512 RS256, RS384, RS512 |
JWE (JSON Web Encryption) | A128CBC-HS256, A192CBC-HS384, A256CBC-HS512 |
JWKs (JSON Web Key) | RS256, RS384, RS512 |
Encryption based |
|
AES-128-CBC, AES-192-CBC, AES-256-CBC Possible to choose between SALTED and UNSALTED encryption | |
DES-EDE3-ECB | |
Plain text | Any URL parameters |
User recognition configuration is centralized in the platform, allowing easy management of various algorithms, including testing and form sampling.
What is user recognition, and why does it matter?
User recognition refers to the process of validating the identity of individuals accessing a system or platform. In a Playable context, user recognition can be a crucial component in creating a seamless user experience for people who interact with your Playable campaigns while maintaining a high level of data security.
Employing user recognition can help ensure:
Efficient data collection: Auto-populate known user data, reducing form completion time and boosting participation.
Enhanced safety: Ensure data integrity, protecting user information from unauthorized access.
Seamless user experience: Make sure that users are automatically identified across web services or apps.
Access control: Ensure only authenticated users can access your campaigns.
Data quality assurance: User recognition prevents data tampering, ensuring the accuracy and reliability of collected information
Supported approaches for user recognition
Playable supports different approaches for user recognition.
JWT based algorithms
Within JWT, we support various standards like JWS (JSON Web Signature), JWE (JSON Web Encryption), and JWKs (JSON Web Key).
JWTs securely identify users by including user information within digitally signed tokens. This prevents anyone from manipulating the data being sent.
There are no restrictions on what data can be included in the payload, so the client decides what information to send. Additionally, only users with valid tokens can participate, ensuring that unauthorized users cannot join the same campaign. This also means, that it is not possible to allow both known and unknown users to access the campaign.
JWS (JSON Web Signature)
Current algorithms supported: HMAC (HS256, HS384, HS512) RSA (RS256, RS384, RS512)
Requirements: Public key (RS only), secret (HS only) & Sample
Example:
JWE (JSON Web Encryption)
Current algorithms supported: A128CBC-HS256, A192CBC-HS384, A256CBC-HS512
Requirements: Secret & sample
Example:
JWKs (JSON Web Key)
Current algorithms supported: RSA (RS256, RS384, RS512)
Requirements: Endpoint URL (external), claims (validation) & sample
Encrypted based algorithms (Open SSL)
Within SSL (Secure Sockets Layer), encryption algorithms like AES (Advanced Encryption Standard) and DES (Data Encryption Standard) are employed to safeguard data during transmission.
AES (Advanced Encryption Standard)
With AES encryption it is possible to allow unrecognized users to access the campaign. This means, that players who enter the game without a token can still access the game, but their credentials won't be automatically identified.
Current algorithms supported: AES-128-CBC, AES-192-CBC, AES-256-CBC
Possible to choose between SALTED and UNSALTED encryption
Requirements SALTED encryption: Password, salt key & iterations
Salting: Accepts PBKDF2C salting
Iterations: 10000 is the default recommendation for the Initialization Vector.
Requirements UNSALTED encryption: Key, IV & sample
Key: Accepts Base64 and HEX
IV: Accepts Base64 and HEX, must contain 16 bytes.
Example of unsalted encryption:
DES (Data Encryption Standard)
DES is compatible with Salesforce
Current algorithms supported: DES-EDE3-ECB
Requirements: Password, padding (optional) & sample
Plain text user recognition
When using plain text user recognition, players are recognized by passing user data via plain text URL parameters.
Allow unrecognized users: With plain text recognition, you can allow unrecognized users to access the campaign as well. This means, that players who enter the game without parameters in the URL can still access the game, but their credentials won't be automatically identified.
Example of plain text user recognition:
Sample format
In the user recognition setup, you must include a full URL with parameters including tokens to validate the key or secret provided.
The sample URL consists of three elements: a question mark, a parameter (often token or query), an equal sign, and the sample.
Mapping encrypted data to registration form fields
Once you have configured the encryption settings and the sample has been approved, you will be able to match the encrypted data points with fields in the registration form.
Additional settings
Additional validation points
For the JWT options (JWS, JWKs and JWE) you can enable specific validation.
Per default, the platform checks if the JWT has expired, but you can also add validation to check the following:
Issued at: Helps verify the token's freshness and whether the token is still valid
Not before: Defines the time before which the JWT must not be accepted for processing
Audience: Identifies the intended audience for the JWT. With this option you will specify an audience value which the platform validates against.
Messages
Another new feature that has been made available is the option to define messages that are displayed to the player, if a token is missing, has expired or if the token was for some reason not accepted.
You can decide whether you want to:
Display a message
Redirect players to a different URL
Send players to a specific flow page you created for this purpose
Display encrypted values in the campaign
Per default, encrypted data is not available to be used or displayed within the campaign.
If you want to use one or more encrypted data point(s) in your campaign, for example display a user name in combination with a replacement tag or a leaderboard, you can enable the setting 'available to display in campaign'.
This way you can manually control what values can be used or displayed in the game.
Note! Enabling the setting will not make the value visible in the registration form.
The setting will only make the value available to be used in the frontend builder. It is up to you to decide, how to display the value in the game.
Testing a user recognition setup
It is a good idea to test your user recognition configuration to check that all datapoints are collected correctly in your registration form.
To test the UR setup in the demo version of the campaign, you can do the following:
Copy the sample (including ? and parameter)
Paste it in the end of the demo URL
Reload the campaign
Check the activity tab to verify that the encrypted data has been submitted correctly
Tip! If your JWT sample has expired, you can disable the 'check expiration' checkbox. By doing this, the platform will allow access, regardless of whether the token has expired. Remember to enable the setting again once you are done testing!