A standalone identity provider, built so applications don't have to reinvent one
Si-des Auth centralizes authentication, session policy, and identity data for multiple tenant organizations behind standards-based OAuth 2.0 / OpenID Connect and a hardened SOAP gateway for legacy enterprise integrations — so every application team isn't independently re-implementing password hashing, token issuance, and session revocation, and getting subtly different parts of it wrong.
Fewer teams touching secrets
One audited codebase hashes passwords, issues tokens, and enforces session policy — application teams consume standard OAuth 2.0 flows instead of storing credentials themselves.
Multi-tenant by construction
Every tenant organization gets its own users, applications, branding, and policy — isolated at the data layer, not just in the UI.
Security signal, not just a login box
Impossible-travel detection, credential-stuffing indicators, and progressive lockout run continuously without slowing down the authentication path itself.
Trust Boundaries & Data Isolation
Every hop between a browser and the data it can reach crosses an explicit, enforced boundary.
Browser / client → ingress
HTTPS-only. Authentication cookies are HttpOnly, Secure in production, and SameSite=Lax.
Request → tenant boundary
Every admin and platform API call resolves its tenant from the authenticated session, never from a client-supplied tenantId. A request for a resource in the wrong tenant returns 404, not 403 — so its existence is never confirmed to the wrong caller.
Application → storage
A single durable storage interface backs every entity (tenants, users, sessions, tokens, security events). The same interface is implemented by a real DynamoDB adapter for production and a file-backed adapter for local development — never an adapter that only lives in process memory.
Application → signing keys
Token signing goes through a key provider interface backed by durable storage by default, with a real AWS KMS-backed implementation that activates the moment a KMS key is configured — no code changes required to switch.
Application → email
Transactional mail goes through a swappable adapter currently pointed at GoDaddy Professional Email, so the provider can change without touching authentication workflows.
Who Uses Si-des Auth
Five roles, each with an access boundary enforced server-side — never assumed from the UI alone.
| Role | Responsibility | Where |
|---|---|---|
| Platform Administrator | Operates the service itself; creates and manages tenant workspaces. | /platform |
| Tenant Administrator | Manages applications, users, MFA/session policy, and branding for one tenant. | /admin |
| Tenant Developer | Integrates client applications using the developer documentation. | /docs |
| Security / Audit Reviewer | Read-only access to audit trails and security events for a delegated tenant. | /admin (events, overview) |
| End User | Registers, authenticates, enrolls MFA, and manages their own sessions. | /sessions |
Why Analytics Run Asynchronously
A login should never wait on a behavioral-risk calculation. Security events (logins, MFA challenges, token refreshes, session changes) are recorded immediately, but the heavier evaluation — impossible-travel velocity, credential-stuffing correlation across a time window — runs out of band and only feeds back into the request path when a decision, like a step-up challenge, actually depends on it. If that evaluation is slow or briefly unavailable, sign-in still succeeds; the platform degrades non-critical analytics before it degrades the ability to log in.