Confirm the authenticity of identified users through our client SDKs
When an end user logs into your application you identify them with mtribes through one of our SDKs. This identification process builds an accurate picture of your user-base inside mtribes, helping you make intelligent targeting decisions.
To ensure the authenticity of an identified user you can enable
Trusted Identity for each of your client SDKs.
How does Trusted Identity work?
Trusted Identity is the process of including a signed user identifier when
session.start(...) call through one of our client SDKs.
This signature is created on your server using a shared platform secret found under your mtribes Space settings.
The process of creating the signature involves taking the unique id of your user and encrypting it with HMAC-SHA256, using the shared secret for the platform they're using. The output is then encoded as a hexadecimal string.
As an example, a
Node.js server may generate a signature for your iOS client
when iOS Trusted Identity is enabled.
signed value must be passed to your app and included in the
session.start(...) call for that user. See the
getting start guide to view examples for each client SDK.
Our platform verifies the signature given the shared secret and rejects any that are invalid. This process allows us to trust the origin starting a session and reject any potentially malicious actors.
Are visitors included?
As visitors are entirely anonymous it's not possible to enable Trusted Identity for them.
When to use Trusted Identity?
We recommend you use Trusted Identity in most situations to ensure the validity of all identified users in your mtribes Space.
In a production environment we strongly recommend you enable Trusted Identity for each of your client SDKs.
How to enable Trusted Identity?
To enabled Trusted Identity follow these steps.
- Visit your mtribes Space settings
and select the
- Copy the secret for the client platform you wish to protect and store this
password in a secure place that can be fed to your server.
- Never share secrets or commit them to source control
- Secrets should only be stored server-side and never in client apps
- When a user logs into your system from a client application, your server should sign their user id with the appropriate secret given their platform and return it to the client.
- In the client application call
session.start(...)and include the
signedvalue returned from the server as an option. You can view examples for each platform through the getting started guide.
- Once the previous steps are in place and deployed to your users, you can toggle on the Trusted Identity mode for that client platform in the Space Space settings.
Only enable once deployed
Ensure you have signing in place for your client platform, and that it's fully rolled out, before you enable its Trusted Identity. Otherwise session start requests may be blocked.