Arquitectura
Antes de integrar Prysm:ID conviene entender una decisión de fondo que hace todo lo demás coherente: cada workspace tiene su propia instancia dedicada. No es marketing — es la forma del producto.
El modelo en una frase
Sección titulada «El modelo en una frase»Un workspace de Prysm:ID = una instancia dedicada, con su propio dominio (
auth.<slug>.prysmid.com), su propia base de usuarios, su propio key store, su propio audit log.
Cuando vos te registrás como cliente de Prysm:ID, te aprovisionamos una stack independiente. Cuando tu cliente te audite y pregunte “¿comparten base de datos con otros tenants?”, la respuesta es no.
Por qué importa
Sección titulada «Por qué importa»La industria de auth B2B mayormente vende multi-tenancy lógico: una sola base, todos los tenants conviviendo, separados por una columna tenant_id. Es eficiente para el proveedor y suficiente para muchos casos. Pero rompe en tres ejes:
1. Aislamiento de datos.
Un bug de query (WHERE tenant_id = ? faltando) expone datos cross-tenant. Hay precedentes públicos. Aislar físicamente elimina esa clase de bug.
2. Compliance. LGPD, Habeas Data, SOC2 enterprise: el auditor pregunta “¿dónde viven los datos de mi empresa?”. Con instance dedicada, la respuesta es “en este host, este DB, este key store” — no “en una columna entre los datos de 50.000 otros clientes”.
3. Portabilidad. Si querés irte, el export de tu instancia es completo y autocontenido. Levantás tu propia infraestructura, importás el dump, apuntás el DNS. No hay “dependencia de tablas compartidas”.
Cómo se ve en la práctica
Sección titulada «Cómo se ve en la práctica» Prysm:ID Platform┌──────────────────────────────────────────────────────────────────────┐│ ││ app.prysmid.com ◀── tu (admin) ──┐ ││ api.prysmid.com ◀── tu app ──────┤ ── plano de control ││ npx @prysmid/mcp ◀── tu agente ───┘ ││ ││ ┌──────────────────────────────┐ ┌──────────────────────────────┐ ││ │ workspace acme │ │ workspace globex │ ││ │ ─ auth.acme.prysmid.com │ │ ─ auth.globex.prysmid.com │ ││ │ ─ instancia dedicada │ │ ─ instancia dedicada │ ││ │ ─ DB schema propio │ │ ─ DB schema propio │ ││ │ ─ JWKS propio │ │ ─ JWKS propio │ ││ │ ─ usuarios, IdPs, apps │ │ ─ usuarios, IdPs, apps │ ││ └──────────────────────────────┘ └──────────────────────────────┘ ││ ▲ ▲ │└───────────┼──────────────────────────────────┼───────────────────────┘ │ │ usuarios de acme usuarios de globexPlano de control (app.prysmid.com, api.prysmid.com, npx @prysmid/mcp): donde vos administrás tus workspaces. Acá está el dashboard, los webhooks, el billing, la API y el MCP.
Plano de datos (auth.<slug>.prysmid.com): la instancia dedicada de tu workspace. Tus usuarios finales hablan acá para hacer login. Tu app habla acá para validar JWTs vía JWKS.
Los dos planos están separados por diseño. Un outage en app.prysmid.com no detiene los logins de tus usuarios — su instancia sigue ahí.
Términos que conviene fijar
Sección titulada «Términos que conviene fijar»| Término | Qué es | Quién lo posee |
|---|---|---|
| Workspace | Tu cuenta en Prysm:ID. Una organización tuya. | Vos (cliente Prysm:ID) |
| Instance | El motor de auth de tu workspace. Una por workspace. | Vos (Prysm:ID la opera) |
| Tenant | Tu cliente B2B. Vive dentro de tu instancia. | Vos (creás uno por cada cliente tuyo) |
| Project | Una “app lógica” agrupadora. Contiene clients OIDC. | Vos (uno por app que registrás) |
| OAuth client | Una app concreta (web, móvil, SPA) con su client_id/secret. | Vos |
| User | Una persona física que se loguea. Vive en tu instance. | Vos (Prysm:ID lo persiste) |