All work

Product

MW Identity

Shared sign-in, e-mail and Google authorization for connected apps.

Shared services for apps integrated with MattediWorks. MW Identity provides sign-in through OIDC, with passkey support. MW Mail sends e-mail through a Resend adapter, and MW OAuth handles Google authorization and delivers the result to the requesting app. One admin console manages the three services. Working On It and NightMare use MW Identity for sign-in; Working On It also uses MW Mail.

Public case study · sign-in for app

Case studyOpen app

Shared services, independent apps

Working On It and NightMare use MW Identity for sign-in; Working On It also sends e-mail through MW Mail. The apps keep their own business data. Identity, the Resend mail gateway and the Google authorization broker share administration without becoming one application database.

Why I built these services

Part of it was learning Go by building something real instead of another example project. The rest came from the apps themselves: as MattediWorks grew, each one was about to rebuild the same infrastructure.

MW Mail started as a gateway in front of Resend: usage and limits per project and delivery tracking, so integrated apps could use one internal API. MW OAuth centralized Google authorization and callbacks, leaving the consuming app responsible for the credentials and data it receives. MW Identity added shared accounts, app access and administration for connected apps, and grew into the control plane.

Keycloak and ZITADEL already offer SSO, OIDC, MFA and identity management, and they are far more mature and complete. They could have met the identity requirements. What I wanted was a scoped implementation I understand end to end, integrated with the rest of MattediWorks and free to evolve with it.

The trade-off is real: building identity infrastructure means owning its security, maintenance and correctness. I am not claiming that is better than adopting a mature platform.

What connected apps share

  • One account, passkey first

    Sign in once with a passkey, with an authenticator app as a fallback. Apps that need it can refuse a password on its own.

  • Leave any app

    People see every app they are connected to and can disconnect from one or all. Every app must handle account deletion.

  • A shared e-mail gateway

    Integrated apps send through MW Mail instead of calling Resend directly. Requests use a project-scoped idempotency key so retries can reuse a recorded send result.

  • Google authorization through a broker

    MW OAuth handles the Google authorization flow and delivers a signed result to the requesting app. The broker processes provider tokens in memory without persisting them; the receiving app manages the credentials it needs.

  • One console for three services

    Register apps, rotate keys and manage Identity, Mail and OAuth projects from one place. Protected operations require a recent passkey authentication.

  • Audited by person

    An admin call made through the console is recorded under the person who made it, not under the service in between.

Implementation context

Team
Solo, design to deploy
Period
2026-08 – now
Status
Live; used by Working On It and NightMare
Tests
339 automated (207 Go, 132 console)

Security boundaries and trade-offs

  • Admin bearer tokens stay in the BFF

    The admin console authenticates to the BFF with an HttpOnly session cookie and uses CSRF tokens for mutations. Identity and delegated bearer tokens stay server-side in the BFF rather than being exposed to console JavaScript. This limits bearer-token exposure; it does not prevent malicious JavaScript from making requests through an active session. The cost is an additional service between the console and the admin APIs.

  • Delegated tokens: one audience, five minutes

    For each admin call the BFF exchanges its session for a token (RFC 8693) that only one service accepts, for one route's scope, for five minutes. A service may only introspect tokens meant for itself, and if Identity is down the request is refused: fail closed.

  • No "forgot password" e-mail, on purpose

    Account recovery goes through an operator rather than an e-mail reset link. The recovery flow revokes existing sessions and tokens and issues a single-use capability to register a replacement passkey. Control of an inbox alone is not enough to complete this flow; recovery still depends on the operator verifying the person's identity.

  • Security rules are tests, not guidelines

    The control plane documents 21 security invariants and tests them end to end: wrong audience, missing scope, Identity outage and unmapped routes all have checks. The BFF is never a generic proxy: every route names its method, path and scope, and anything unmapped is a 404.

Identity, BFF, Mail and OAuth

The admin console talks only to mw-bff, using an HttpOnly cookie. mw-bff holds the session with mw-identity and gets five-minute delegated tokens to call MW Mail and MW OAuth, which introspect them against mw-identity. Apps such as Working On It and NightMare sign people in through mw-identity over OIDC.HttpOnlysession · delegationtoken · 5 mintoken · 5 minintrospectintrospectsign-inAdmin consoleReact 19mw-bffGoMW MailGo · SQLiteMW OAuthGo · SQLitemw-identityGo · OIDC · SQLiteWOI · NightMareOIDC clients
  • mw-identity: the OIDC provider, in Go, on SQLite.
  • mw-bff: the admin backend-for-frontend, in Go; the React 19 console talks only to it.
  • MW Mail (Resend adapter) and MW OAuth (Google adapter): Go and SQLite, each with its own public API for apps, authenticated by project keys.
  • In federated admin mode, MW Mail and MW OAuth validate delegated tokens through introspection against mw-identity.

Scope and security review

  • Single instance on SQLite.
  • No external security audit yet.
  • Private repositories; the end-user story is public at mwecosystem.mattediworks.com.