Platform / Authentication & Identity
Sign-in you never have to build.
Every Maestra app gets production identity and access control from the platform, not from the app. The app declares who its users are and what each role can do. The platform verifies identity, issues sessions, checks roles on every call, and revokes access, all at its own boundary. App code never stores a password, signs a token, or decides for itself whether a request is allowed.
Where quick apps become liabilities
A workforce shipping its own software is a good thing, right up to the sign-in screen. Identity and access are where a quickly built app quietly turns into a liability: a hand-rolled login, a password stored somewhere it shouldn’t be, no way to revoke a session, a permission checked in the interface but not the backend.
Maestra removes the question by structure. Every request to every app passes through one platform edge, where identity and access are both settled before app code runs.
The app declares. The platform enforces.
Authentication happens at the platform boundary, before any app code runs. Three things follow, and none of them are the builder’s job:
- No credentials in the app
- It never stores or checks a password and never signs a token. There is no home-grown credential store to leak.
- No gaps to leave open
- Every backend call and database read goes through an authenticated platform endpoint, so there is no accidental public surface.
- The same everywhere
- One session model, one revocation path, one set of audit events across the fleet. Security posture doesn’t depend on who built the app.
An app turns all of this on by declaring, in a few lines, that it has users and which roles they can hold. The platform supplies everything else.
Sign in with Maestra
The organization path replaces app-local accounts with federated single sign-on, with Maestra as the identity broker. Your corporate directory federates into Maestra over SAML 2.0 or OIDC, and Maestra issues a credential-free session to each app your people build. Your directory stays the system of record, and your existing MFA and conditional-access policies apply at that boundary.
Roles, enforced at the edge
Authentication answers who someone is. Authorization answers what they can do, and it is where hand-built apps fail quietly. Maestra checks roles at the same edge that handles sign-in.
| Member | Deal desk | Month-end close | Supplier queue | Metrics board |
|---|---|---|---|---|
| DWDana Whitfield Ops | Approver | Approver | — | Viewer |
| MRMarcus Reyes Sales | Rep | — | — | Viewer |
| PRPriya Raman Finance | — | Preparer | Requester | Editor |
| JTJesse Tran Procurement | — | — | Buyer | — |
| BCBea Coleman Contractor | — | — | — | Viewer |
Governed from one place
- Roles from your directory
- Map directory groups to roles once. Join a group and you get the role wherever it applies; leave and it’s gone.
- Offboarding that reaches everything
- Remove someone from the organization and every session and permission drops across every app at once.
- One access review
- Every person, every app they can reach, and their role in each, in a single view.
- One audit trail
- Sign-ins, role changes, grants, and denials recorded as structured events, exportable in OCSF. See the Audit Log deep dive.
The guarantees
- Server-side authorization
- Role checks run at the platform boundary, never only in the interface.
- Signed session cookie
- Per-app, HttpOnly, Secure, SameSite, origin-scoped.
- Single-use handshake
- App-bound, redeemed on the app’s own origin, expires in about a minute.
- Immediate revocation
- Offboarding drops every session across the organization’s apps at once.
- Admin-locked limits
- Session ceilings and role definitions belong to the org admin. A builder can’t loosen them.
Start building on Maestra.
Everything you just read is standard in every app, running from the first deploy.
Start building →← Back to the Platform