Skip to main content
User recognition
Asta Dybdal avatar
Written by Asta Dybdal
Updated over a week ago

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:

  1. Copy the sample (including ? and parameter)

  2. Paste it in the end of the demo URL

  3. Reload the campaign

  4. 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!

Did this answer your question?