Skip to content
Me2eM

Multi-App SSO

One Me2eM instance lets a user into every application in the ecosystem. The account is a seed phrase: there is no user database — nothing to maintain, leak, or correlate.

Stateless auth — no session database User database cannot leak Correlation — user's choice Sign out of all devices — one revocation

View live site
Table of contents Show Hide

What you can build

A fleet of applications behind one sign-in: every app in the ecosystem accepts the same identity, the user types the seed phrase once — at the first app — and every other app logs them in automatically. Zero registered accounts: the instance stores no profiles, no emails, no password hashes.

How it works

Each app receives its own Handle derived from the user’s seed. The instance issues a session per app and keeps an HttpOnly cookie for its own domain; the next app in the ecosystem recognizes the cookie and signs the user in.

sequenceDiagram
    participant U as User
    participant A as App A (taxi)
    participant M as Me2eM instance
    participant B as App B (freelance)
    U->>A: enters seed phrase (locally)
    A->>M: auth request, Handle @taxi
    M->>A: session token + HttpOnly cookie
    U->>B: opens App B
    B->>M: cookie check
    M->>B: session confirmed — auto login

Apps inside your perimeter verify tokens statelessly with verifyStateless (Mode 1); external partner apps verify attestation chains with the root public key only (verifyAttested, Mode 2). Backends need no session store — one signature check per request.

Benefits

  • No user database. Nothing to register, nothing to leak; the instance stores only hashed refresh tokens and revoked jti entries.
  • Instant onboarding. A new user costs the instance nothing — derivation happens on the client.
  • Correlation is opt-in. Every app sees a different Handle; taxi and freelance cannot link the same person unless the user reuses one Handle deliberately.
  • “Log out everywhere” is a revocation entry, not a database wipe.

Trade-offs

  • The seed is the only key back in. Lose the phrase — lose every account in the ecosystem; there is no reset by design.
  • An instance must run. SSO needs the Me2eM service (cloud or self-hosted) reachable at sign-in; it is infrastructure, not a static asset.
  • Same-domain requirement. Cookie auto-login works for apps under the instance’s domain (or subdomains); fully external apps go through Mode 2 instead.
  • Alpha. Package APIs are pre-1.0; pin versions.

References

More use cases

UC-1

AI Agent Delegation

Give an autonomous AI agent its own cryptographic identity and a signed mandate from its owner. One call revokes a compromised agent — across every service it touches.

#ai-agents #attestation #revocation #stateless
UC-2

Satellite Capacity Marketplace

Sell time-boxed slices of spacecraft resources — EO tasking windows, transponder leasing, downlink capacity. The buyer receives a signed receipt verifiable with your public key alone.

#space #attestation #offline #stateless
UC-2

Drone Fleet Management

Provision airframes at deploy, isolate onboard subsystems, grant a technician 48 hours of maintenance access from the hangar — and kill a lost drone in one call.

#drones #attestation #offline #revocation

Your scenario not listed here?

The protocol's terms are domain-neutral — new scenarios map to the same primitives. Start with a quick start or read how attestations carry delegatable trust.

Read the docs All use cases