Application Users

Authentication

Use your existing identity provider for app users, such as Keycloak or Auth0. If you don't have one, use an authentication library such as Better Auth.

Reserve Monospace user accounts for people who need direct access to the Studio, API, or MCP server. Don't create Monospace accounts for people who only use your app.

Monospace SSO lets those Monospace users sign in with an identity provider. Configure your app's sign-in separately.

User Relations

To link app data to a user, use a collection -- a container for items of the same type. Each item's named values are its fields.

You can also keep a Users collection in Monospace for app profiles and user-linked data. Authentication stays with your provider or library; these items are separate from Monospace user accounts.

For a blog where app users write articles:

1. Create a Users collection with a user_id primary key. Store the user ID from your identity provider or auth library in that field.
2. Store app profile data, such as display_name, on the same item.
3. Add an author relation to Articles, pointing to Users.user_id. This to-one relation links each article to one author.

If your data model already has a collection keyed by those user IDs, link to that collection instead.

Use a regular Relation field for these links. The built-in User field targets Monospace workspace members, so it doesn't represent your app's external users.

Links to Monospace Accounts

If an app user also needs Studio, API, or MCP access, link their custom Users item to their Monospace account.

In the Studio, add a User field named monospace_user to your Users collection and choose Single User. Set it to the matching workspace member, keeping the external auth ID in user_id.

Keep this field optional so app users without Monospace access remain unlinked. Turn on Exclusive if each Monospace member must link to at most one custom user item.

This creates a one-to-one relation that dynamic permission filters can follow to your custom profile data.

Server Access

Connect your app's backend to Monospace with a scoped service account, keeping its API key on the server. Validate app sessions and enforce each app user's access in your backend before calling Monospace.

Monospace applies the service account's permissions to those requests. $CURRENT_USER identifies that service account, not the app user signed in through your auth system.

See Also

• Authentication -- authenticate your backend's Monospace requests
• Data Model -- configure relations between collections
• Access & Permissions -- scope your service account's access