Identity and access
Separate credential, route, and resource decisions in an application.
Cloud owns accounts, sessions, credentials, roles, groups, and permission primitives so every installed application receives the same caller model. Your application remains the authority for its own resources and domain operations.
That split matters most for independently deployed applications: they can trust Cloud to establish an identity without giving Cloud enough information to decide whether that identity may read or change an app-owned resource.
Keep three boundaries separate on every request:
| Boundary | Question | Owner |
|---|---|---|
| Authentication | Is the credential valid, and who acted? | Cloud authentication |
| Route policy | May this kind of caller enter the route? | Application middleware |
| Resource authorization | May this caller perform this operation on this resource now? | Application service |
A valid login does not grant access to every resource. A route role does not replace a resource permission check. Every entry point that reaches the same domain operation—HTTP, SSR, capability, CLI, or background work—should converge on the same permission-aware application service.
Continue by task
| Task | Page |
|---|---|
| Understand the actor and access subject | Request identity |
| Assign local Linux attributes and backfill existing accounts alongside FreeIPA | Linux identities |
| Decide who may enter a route | Route policies |
| Check access to one domain resource | Resource authorization |
| Create a credential for one resource | Resource API keys |
| Integrate an OAuth client | OAuth |
| Allow a route without a session | Public access |
OAuth and API keys change how Cloud establishes the actor; they do not create a second authorization model. Public access likewise opens only the route and resources the application explicitly makes public.