Application Data Persistence and Sharing
Trivore ID can store small amounts of application-specific data, using a few different persistence methods suited to different kinds of data. This page covers the basics of each method and how to decide between them, and describes where data logically lives for both user accounts and applications/services — since both own similar kinds of data, and both may share data with each other, in a controlled way.
There are two private data types, one per user account: user tags and user custom fields. There are also two public data types with similar access control and usage patterns: user tokens are simple key-value pairs, while a data storage can hold much more.
A few terms are worth covering before the rest of this page.
Access control
Access control is, broadly, the means to allow or deny access; the default is always to deny.
Access control is typically defined as one list for read-write access and one for read-only access — if a user account or Management API Client appears in a list, it gets the corresponding access. The terms access control list (ACL) and access control entry (ACE) are common; an ACE is a single entry in an ACL. Access control is purely a security mechanism, separate from permission management.
A different layer is OAuth 2.0 and the user access token a user account receives when signing in to Trivore ID's OpenID Connect provider — this is a way for the user themselves to gain access, and may grant access to additional data.
Similarly, integrating applications and services typically have a Management API Client defined for them, with its own security credentials and its own set of allocated permissions that give it access to data and functionality.
These three — access control, user access tokens, and Management API Client permissions — are independent layers. All three need to be considered together to understand what a given caller can actually access.
User-related data persistence
These persistence methods all relate to user accounts in some way.
User tags
User tags are short strings attached to a user account. They're indexed, so accounts can be queried by tag — think of a tag as the name of a lightweight, ad hoc group. Trivore ID doesn't interpret tags itself; their meaning is entirely up to the applications that use them.
A namespace can define default tags, which are then suggested in the tag field of the user
editor in the Management UI. Users can edit their own tags without any special permission;
Management API Clients and users with the ACCOUNT_MODIFY permission can change tags on any
user account in a namespace they can access.
See Tags for more on using tags effectively.
User custom fields
Custom fields are freely-defined field names and values (string, boolean, number, or object),
used to attach application-specific data to a user account. They can also be used in user
search, via filter keys like customFields.{fieldName}.
Custom fields are visible to the user themselves, and to any Management API Client with the
ACCOUNTS_VIEW permission and access to the user's namespace; a client with ACCOUNTS_MODIFY
and the same namespace access can also modify them.
User tokens
User tokens are access-controlled key-value pairs attached to a user account: one list of entities (users, groups, or Management API Clients) may read a token, and another list may modify it. A token's value can be any string, including JSON or base64-encoded binary data. Tokens can be queried by user ID and key.
Generic data persistence
A data storage isn't tied to user accounts at all — it can hold any application-specific data.
See its own page for detailed limitations; every Trivore ID instance's /apidoc page also
documents the REST endpoints for this method.
Data storages
A Data Storage is a lightweight database for structured, searchable JSON data — not a full relational database, but enough for most cloud and mobile-first application use cases. It has built-in access control that can grant read-only or read-write access to users, groups, or Management API Clients.
Comparison
| Data type | Scope | REST API | Accessible with | Max amount | Considerations |
|---|---|---|---|---|---|
| User account custom fields | User account | /api/rest/v1/user/{userId}/customfields | User access token, Management API Client credentials | Limited by the combined user document size limit | Managed in bulk via REST — take care when sharing between services. |
| User tokens | User account | /api/rest/v1/user/{userId}/token | User access token, Management API Client credentials, access control | Multiple per user; see size table below | Good for smaller-volume, controlled data sharing. |
| Data storage | Anything (varies per storage) | /api/rest/v1/datastorage | User access token, Management API Client credentials, access control | Unlimited storages; see size table below for one storage | Very performant; each storage can have its own access control. |
| User account (including identity data and tags) | User account | /api/rest/v1/user, /api/rest/v1/user/{userId}/profile, OpenID /openid/userinfo | User access token, Management API Client credentials | See size table below | Holds auxiliary account data and all identity data. |
The table below shows maximum data sizes — total size includes keys, names, and metadata, not just the payload itself.
| Data type(s) | Maximum size | Allowance |
|---|---|---|
| User account (including tags, custom fields, identity data) | 16 MB per user account | Unlimited number of user accounts |
| User tokens | 16 MB per token | Unlimited number of tokens |
| Data storage | 16 MB per storage, holding multiple key-data pairs | Unlimited number of data storages |