Identity provider
A base for login, sessions and identity flows across WebEdge systems.
WebEdge project
Identity provider
Challenge
Repeating authentication in every app would be slow and risky.
What we did
We separated identity logic into a standalone module with typed flows and integrations.
Result
New products can rely on one login foundation instead of separate implementations.
Dev-story article
Identity provider: how the project was built
Repeating authentication in every WebEdge product would create inconsistent session behavior and extra risk. This project separates identity concerns into a shared foundation that other apps can depend on.
Sections
06
Modules
04
Stack
TypeScript + Convex
Why the project exists
Repeating authentication in every app would be slow and risky.
Repeating authentication in every WebEdge product would create inconsistent session behavior and extra risk. This project separates identity concerns into a shared foundation that other apps can depend on.
What was built
We separated identity logic into a standalone module with typed flows and integrations.
The identity provider defines login flows, session records, user identity fields and integration boundaries for products that need the same authentication base. Each app gets a common way to ask who the user is and what session is active.
Main modules and user path
Login and session workflows model sign-in, active sessions, expiry and account state as typed records instead of screen-specific flags.
OIDC-style boundaries keep the identity layer separate from product features, letting an app consume identity data without owning the login process.
User profile and account records provide a shared source for identifiers, display data and role-related fields.
Administrative checks help review sessions and identity records when support or operations teams need to understand access state.
Architecture and technology decisions
Technical foundation: TypeScript, Convex, OIDC. This matters not as a logo list, but as the set of choices that keeps data, state, user actions and future maintenance manageable.
TypeScript and Convex support a typed flow model where session state is explicit. Login behavior stays behind a dedicated module instead of spreading across apps.
How it works in a real scenario
In real use, “Identity provider” works as a clear sequence: it starts from the original problem, then the user takes the primary action, follows a clear data path and reaches the result. The experience stays logical instead of being a random set of screens.
The practical value shows where manual work used to be needed: part of the process is automated, responsibilities are clearly separated, and each module does one understandable job. That is what keeps the solution easy to maintain and extend.
Result and lessons
New products can rely on one login foundation instead of separate implementations.
New products can start from one login foundation. Duplicated code drops, and the team gets a clearer place to maintain identity flows over time.
Related articles
Read next
Related project stories
These projects share nearby technical or product decisions, so they show how the same principle behaves in another context.
Dev-storyWebEdge CMS and public content API
Content management that feeds websites and lets the team publish without developer intervention.
WebEdge project
Self-hosted reactive database platform
Self-hosted reactive database platform
An experimental data layer for real-time apps and infrastructure control.
WebEdge project
Convex Vue Query adapter
Convex Vue Query adapter
A library-style module connecting Convex data with Vue Query workflows.
Have a similar idea?
Discuss your project