Getting started
Architecture
What your browser, your backend and DevSewa each hold, and why the split is what keeps secrets out of the wrong place.
Three parties, three responsibilities
| Party | Holds | Talks to |
|---|---|---|
| Browser | Nothing secret. At most a Client ID. | Your backend; DevSewa hosted sign-in (redirect only) |
| Your backend | The client secret for each application | DevSewa’s API with a Bearer key |
| DevSewa control plane | Every engine credential, your policy, the audit log | Identity, mail and vault engines with credentials only it holds |
Edge and authority
DevSewa itself is split in two. The edge — this site and the console — is stateless: it renders UI and forwards actor-scoped requests. The authority core owns the database, the registered applications and the credentials for every engine. The edge cannot reach an engine and never holds a secret, so a compromised edge yields nothing worth having.
Each capability has its own hostname (auth.api, mail.api, vault.api) so a product can later move to its own core without changing what you call.
Engines are shared; your configuration is not
The identity, mail and vault engines serve several products on the fleet. None of your configuration — callbacks, policy, sender domain, keys — lives in an engine. It lives in DevSewa, keyed by your application, and is applied at the mediation layer on every call. That is also where MFA and e-mail verification are enforced, so bypassing your UI gains nothing.