Authentication and user management

What is the planned Authentication and user management module designed to do?

Authentication is the base of an Edict backend. It is planned to cover Apple Sign In, Google Sign In, email authentication, user sessions, user profiles, and account lifecycle management. It is also planned to hold the ownership and access rules that decide which user may read or change which resource.

Most mobile backends start here, and most other features depend on it. A workout record needs an owner. A paywall needs to know which person bought a plan. An AI request needs a user to count against. In Edict, the authentication module is designed to be the single source for that identity, so those features do not each invent their own.

How does the Authentication and user management module connect to other modules?

Modules in Edict are designed to talk through typed contracts instead of integrations you write by hand. Authentication provides the identity contract. The rest of the system reads it.

• Authentication + Database. Records can belong to the signed-in user. A rule such as owner: user is intended to compile into user-scoped authorization, so one person cannot read another person’s rows.
• Authentication + Subscriptions. A purchase is designed to be tied to a user, so the resulting entitlement follows that user across devices.
• Authentication + Subscriptions + AI gateway. Together they are designed to give subscription-gated AI: the gateway checks who is calling, then checks what that person’s plan allows, then meters the request.
• Authentication + Push notifications. Device registrations are designed to be tied to users, so a reminder reaches the right person.

The intent is that you declare the relationship once and the compiler resolves the connections and validates them.

What would you configure in the Authentication and user management module?

You choose the providers, the profile fields you want to keep, and the ownership rule for each kind of record. You also set access policies, for example which resources are private to one user and which a user may share.

The configuration shown on this page is illustrative. The syntax is not final.

What stays your own code with the Authentication and user management module?

The sign-in screens, the onboarding flow, and the wording your users see stay in your app. So does any product decision about who should be allowed to do what. Edict is designed to enforce a rule once you state it. It does not decide the rule for you.

In the intended workflow, your coding agent edits the configuration file, and you review the change like any other diff.

Is the Authentication and user management module available yet?

Planned. Edict is in development, and this module is not available. Each provider integration will be described as working only once it is built and tested. This page describes the intended design and is not a promise of dates or of a final feature set.

If you want to follow progress, join the beta waitlist.