Before you can effectively implement Monime’s authentication system, you need to understand three fundamental concepts that form its foundation: Spaces, Monimeers, and Personal Access Tokens. These aren’t just terminology; they represent the architectural decisions that make Monime’s authentication both powerful and secure.

​
Spaces: Your Isolation Boundary

A Space in Monime is a completely isolated environment that belongs to a single business or organization. Think of it as your own private section of the Monime platform where your data, settings, and operations are completely separated from everyone else’s.

​
The Multi-Tenant Architecture

Monime operates on a multi-tenant architecture, which means many Spaces coexist on the same platform infrastructure. This is similar to how multiple companies might have offices in the same building. This architecture provides several critical benefits. First, it enables economies of scale, as the platform infrastructure is shared efficiently across all Spaces. Second, it ensures complete isolation, so problems in one Space never affect another. Third, it allows for Space-specific customization while maintaining platform-wide consistency where needed.

​
Space Boundaries and Security

The boundaries between Spaces are absolute and enforced at every level of the system. When a request attempts to access resources in a Space, the system verifies not only the authentication credentials but also whether those credentials have the appropriate permissions within that specific Space. Personal Access Tokens in Monime have a powerful relationship with Spaces. While tokens are created by Monimeers and can potentially work across multiple Spaces (inheriting the Monimeer’s permissions in each), they can also be optionally bounded to a single Space at creation time. When a token is Space-bounded, it becomes tied to that specific Space and cannot be used elsewhere—like having a key that only works for a room even though you have access to multiple rooms. This flexibility allows for both broad integration scenarios and tightly scoped security requirements.

​
Working with Multiple Spaces

Many organizations use multiple Spaces for different purposes, such as separating production from development, isolating different departments or projects, or creating temporary Spaces for specific initiatives. Monimeers can belong to multiple Spaces simultaneously, potentially with different roles in each, and this flexibility allows Monime to model complex organizational structures accurately.

​
Monimeers: The Actors in Your Space

A Monimeer is any entity that can authenticate and perform actions within Monime’s platform. The term intentionally encompasses both human users and automated systems because, from the authentication system’s perspective, they’re treated similarly—both need to prove their identity and have their permissions verified. Human Monimeers are individuals who interact with the platform through web interfaces, mobile apps, or API tools. They typically authenticate initially through aliases(phone or email) and OTP, then create Personal Access Tokens for API access. Automated Monimeers are scripts, applications, or integrations that interact with the platform programmatically. They authenticate exclusively through Personal Access Tokens and often run without human intervention.

​
Monimeer Identity and Roles

When a Monimeer joins a Space, they’re assigned a role that defines their permissions within that Space. A Monimeer’s identity across the platform consists of several components. Their unique identifier remains constant and provides a permanent reference for audit trails and permission management. In each Space they belong to, they have an assigned role that determines their base permissions within that specific Space. Any role modifications include temporary permission grants or restrictions for specific scenarios. Their activity history includes all authentication events and actions performed across all Spaces they have access to. It’s crucial to understand that a Monimeer’s role is Space-specific. The same individual might be an Administrator in the development Space but have read-only Viewer access in the production Space. This separation allows organizations to implement the principle of least privilege effectively, giving people exactly the access they need in each context, no more and no less.

​
Personal Access Tokens: The Keys to the Kingdom

A Personal Access Token (PAT) is a cryptographically secure string that authenticates API requests on behalf of a Monimeer. Unlike passwords, which are typically short and memorable, PATs are long, random strings that are impossible to guess and difficult to forge. Each token is fundamentally tied to the Monimeer who created it and encodes several pieces of critical information. The Monimeer identifier links the token to its creator for audit and permission purposes. Declared permissions specify what operations the token is intended to perform. Creation timestamp and expiration time define the token’s validity period. An optional Space identifier can bound the token to a specific Space if desired. And a cryptographic signature ensures the token hasn’t been tampered with.

​
Token Creation and Configuration

When a Monimeer creates a Personal Access Token, they’re essentially delegating a subset of their permissions to that token. This delegation follows strict rules to ensure security is maintained. During creation, the Monimeer makes several important decisions. First, they specify what permissions the token should have (its declared permissions). Second, they decide whether the token should work across all Spaces they have access to or be bounded to a single Space. Third, they set how long the token should remain valid. Finally, they can add a description to help identify the token’s purpose later. The choice between a cross-Space token and a Space-bounded token depends on the use case. Cross-Space tokens are ideal for integrations that need to synchronize data across multiple environments or for administrative tools that manage multiple Spaces. Space-bounded tokens are perfect for production systems that should never accidentally access other environments or for third-party integrations that should have limited scope.

​
The Sophisticated Nature of Token Permissions

Personal Access Tokens have a permission model that adapts based on context. A token always carries its declared permissions—what it claims it should be able to do. However, the effective permissions of a token in any given Space are calculated through an intersection model. When a cross-Space token is used to access a particular Space, the system calculates effective permissions by intersecting two sets: the token’s declared permissions and the Monimeer’s current permissions in that Space. This means a single token can have different effective permissions in different Spaces, automatically adapting to the Monimeer’s role in each context.

​
Token Security and Management

The actual token string is shown only once during creation. After that, it is no longer visible for management purposes. This prevents tokens from being casually exposed through administrative interfaces. Tokens can be revoked individually by the Monimeer who created them. When a token is revoked, it immediately stops working. For cross-Space tokens, revocation affects all Spaces. For Space-bounded tokens, the revocation is inherently limited to that Space’s context.

​
How These Concepts Work Together

The true power of Monime’s authentication system emerges from how Spaces, Monimeers, and Personal Access Tokens work together in a powerful dance of permissions and contexts. When an API request arrives with a Personal Access Token, the system follows a comprehensive validation process. First, it verifies the token’s validity and checks if it’s expired or revoked. Then, it identifies which Monimeer created the token. If the token is Space-bounded, the system ensures the request is targeting that specific Space. If it’s a cross-Space token, the system identifies which Space the request is targeting based on the Monime-Space-Id header. Next, the system retrieves the Monimeer’s current role and permissions in the target Space. If the Monimeer doesn’t have access to the target Space, the request is immediately denied. The system then calculates the effective permissions by intersecting the token’s declared permissions with the Monimeer’s permissions in that Space. Finally, it evaluates whether the requested operation falls within these effective permissions. This layered approach means that security can be managed at multiple levels. Space administrators can set broad policies that apply to everyone, role definitions can establish standard permission sets for common job functions, individual Monimeers can have their roles adjusted as needed, and tokens can be scoped to specific tasks without compromising overall security.

​
Practical Implications

Understanding these core concepts has practical implications for how you design and implement your integrations. When planning your token strategy, consider whether your integration needs to work across multiple Spaces or can be limited to one. Cross-Space tokens offer flexibility but require careful permission management to ensure they don’t inadvertently grant too much access in any particular Space. Space-bounded tokens provide an extra layer of security for sensitive operations. When assigning roles to Monimeers, remember that their permissions in each Space directly affect what their tokens can do in that Space. When creating Personal Access Tokens, always declare the minimum permissions necessary for the specific task. Even if you have broad permissions across multiple Spaces, constraining tokens limits damage if they’re compromised. Consider token lifetime carefully—shorter is more secure but requires more management overhead. For automated systems that need to operate across multiple Spaces, you might create a dedicated Monimeer account with carefully calibrated roles in each Space. This Monimeer can then create cross-Space tokens that automatically inherit appropriate permissions in each context.