Configure Auth0, Azure AD, Google, or local credentials once. VividEcho validates JWTs on every request and enforces per-document access rules automatically. There's no separate authorization service to stand up — your existing sign-in flow is the only piece you bring, and VividEcho takes it from there.
Every application runs in one of two authentication modes, decided once when the application is set up. In Enterprise mode, users must be provisioned by an administrator before they can use the app at all — a signed-in user without provisioned access is turned away even with a valid token, which suits internal tools where access is controlled centrally. In B2C mode, users can self-register just by signing in through a supported identity provider, with no administrator step, which suits public-facing consumer apps. Only B2C apps can additionally allow anonymous access, letting signed-out visitors read whatever records you've explicitly opened up to them.
Requests carry the signed-in user's identity as a bearer token in the Authorization header. VividEcho accepts tokens from Auth0, Microsoft Entra ID, Google, and its own built-in local credential store, all recognized simultaneously — so you point it at whichever sign-in your app already uses instead of standardizing on one provider first.
Authorization isn't just per collection — it's set on each individual document via the x-access header when you create or update it. A record can be kept private to its creator, opened up as public for any signed-in user to read and write, made readonly so anyone signed in can read but only the owner can change it, or set to readanonymous so even signed-out visitors can read it (only meaningful on B2C apps that allow anonymous access). Leave the header off entirely and VividEcho falls back to sensible defaults: new records start private, and updates without an explicit access level simply keep whatever the record already had.