Authentication you never have to build.

Where quick apps become liabilities

A workforce shipping its own software is a good thing, right up to the login 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. The usual fix is worse than it sounds, asking every builder to wire up an identity vendor themselves and hoping they got it right.

Remy 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 terminates.

Authentication happens at the platform boundary, before any app code runs. Three things follow from that, and none of them are the developer’s job:

No credentials in the app

It never stores or verifies a password, never signs a token. There’s no home-grown credential store to leak.

The app can’t expose a gap

Every backend call and database read is brokered through an authenticated platform endpoint, so there’s no accidental unauthenticated surface for a developer to leave open.

Consistent across every app

The same session model, revocation path, and audit events apply fleet-wide. Security posture doesn’t vary with who built the app.

An app turns all of this on by declaring, in a few lines of configuration, that it has users and which roles those users can hold. The platform supplies the rest.

That same declaration covers access. The roles an app declares are enforced at the platform boundary: before a method runs, the platform checks that the caller holds the role it requires. A frontend can ask for anything it wants; an unauthorized call is refused before it reaches app code. Authorization isn’t something each app reimplements and hopes it got right.

Sign in with Remy

The enterprise path replaces app-local accounts with federated single sign-on, where Remy is the identity broker. A person signs in with their existing Remy workspace identity; the app trusts Remy’s assertion of who they are and whether they’re allowed.

It’s a standard two-hop federation chain: your corporate directory federates into Remy over SAML 2.0 or OIDC, and Remy is the identity provider for every app your team builds. Your directory stays the system of record, and your existing MFA and conditional-access policies apply at that boundary. Apps never see or store credentials: they redeem a short-lived, single-use, app-bound handshake code for a session, and the credential exchange happens entirely on the platform side.

Roles, enforced at the edge

Authentication answers who someone is. Authorization answers what they can do, and it’s where hand-built apps quietly fail: a check skipped on one endpoint, a permission enforced in the interface but not the backend, an admin action one crafted request away. Remy enforces roles at the same edge that terminates sign-in.

Declared per app

Each app defines its own roles, from a simple admin and member split to finer-grained access, in the same manifest that turns on auth.

Checked on every call

The platform checks the caller’s role at the boundary before the method runs. Enforcement lives on the server, so it holds no matter what the client sends.

Real capability, not labels

A role governs what a person can actually do: which methods they can call, which records they can see, which actions need approval. The interface adapts to the role; the backend enforces it.

The result is one clear picture of who can do what, across every app your organization runs.

Governed from one place

Because identity and roles live in one broker, access is governed centrally instead of app by app.

Roles from your directory

Map corporate directory groups to roles once. Membership then drives access: 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 both their sessions and their access drop across every org-owned app at once, with the next request denied. No per-app accounts to close, no stale permissions to hunt down.

One access review

See every person, every app they can reach, and their role in each, in one place, instead of auditing each app on its own.

One audit trail, SIEM-ready

Sign-ins, role changes, access grants, and denials are recorded as structured events, exportable in OCSF, the schema Splunk and other SIEMs ingest natively. Full detail in the Audit Log deep dive.

The guarantees

Server-side authorization

Role checks run at the platform boundary, never only in the interface, so a client can’t grant itself access.

Signed session cookie

Per-app, HttpOnly, Secure, SameSite, origin-scoped, signed by the platform.

Single-use handshake

The delegated code is app-bound, redeemed on the app’s own origin, and expires in about 60 seconds.

Immediate revocation

An organization offboard drops every one of the user’s sessions across the org’s apps at once.

Admin-locked ceilings

Session limits and the delegated-only requirement belong to the org admin and are enforced by the platform no matter what an app asks for. A builder can’t relax them.

Admin-locked roles

Role definitions and directory-to-role mappings belong to the org admin and are enforced by the platform, so a builder can’t widen their own app’s access.

Open-redirect defense

Delegated redirect targets are checked against a per-app allowlist, and anything malformed fails closed.

None of it written by the app

Your team shipped the app. They didn’t build the sign-in, the sessions, the role checks, or the offboarding, and they couldn’t have weakened any of it if they’d tried. The app declared who its users are and what its roles can do; the platform enforced the rest, the same way, for every app the organization builds. That’s what makes an app built in an afternoon safe enough to hold real identities and real permissions.