La mayoría de los artículos que comparan proveedores de identidad están escritos por... proveedores de identidad. Sorprendente, ¿verdad? Enumeran funciones que su producto tiene, omiten las que no, y lo llaman una "guía objetiva".
Esto no es eso.
Hemos revisado docenas de solicitudes reales de evaluación empresarial: las verdaderas hojas de cálculo y documentos RFP que los equipos de compras envían a los proveedores. Los patrones son claros: los equipos de ingeniería consistentemente subestiman los criterios que más importan y sobrevaloran los que menos.
¿El resultado? Los equipos eligen un IdP basado en una demo, descubren que la historia de migración es una pesadilla a los seis meses y empiezan a evaluar de nuevo.
Aquí tienes el marco de evaluación que nos hubiese gustado tener antes de empezar. Está hecho para equipos de ingeniería de empresas SaaS B2B—los que construyen productos, no los que compran SSO empresarial para empleados.
Respuesta rápida: Lo que hace o deshace una decisión de IdP#
Si solo estás hojeando, aquí tienes la versión corta:
- La profundidad del protocolo importa más que el número de funciones. Decir que soporta "OAuth2" no dice nada. ¿Qué tipos de grants soporta? ¿Puedes personalizar los claims de los tokens? ¿Puedes convertirte en proveedor OIDC tú mismo?
- La capacidad de migración es el criterio menos valorado y más crítico. Si no puedes migrar tus usuarios actuales sin forzar reinicios de contraseña, el IdP es inutilizable—sin importar lo bien que se vea el resto.
- La multiarrendación debe ser nativa, no un añadido. Si los modelos de organización y configuraciones por tenant necesitan soluciones improvisadas, estarás luchando contra el sistema para siempre.
- La preparación para IA no es planificación a futuro—es un requisito a 12 meses. Intercambio de tokens, identidad de agentes, scopes delegados. Si el IdP no los soporta, volverás a evaluar el próximo año.
El resto de esta guía profundiza en cada dimensión de evaluación, con preguntas específicas que hacer y señales de alerta a vigilar.
Para quién es esta guía (y para quién no)#
Esta guía es para ti si:
- Eres CTO, VP de Ingeniería o arquitecto de plataforma en una empresa SaaS B2B de entre 50 y 300 personas
- Tienes más de 100,000 usuarios y no puedes permitirte una migración disruptiva
- Estás apuntando hacia clientes empresariales que necesitan SSO, modelos de organización y registros de auditoría
- Necesitas escribir un informe de evaluación técnica y quieres un marco que no provenga de un proveedor
NO es para ti si:
- Buscas IAM para empleados (SSO interno)—es una decisión de compra diferente
- Eres una startup con 500 usuarios y sin clientes empresariales—aquí elige la mejor SDK y sigue adelante
- Necesitas verificación de identidad (KYC/KYB)—eso es otra categoría totalmente distinta
Dimensión 1: Capacidades de protocolo—No solo "soporta OAuth2"#
Todos los IdP te dirán que soportan OAuth2 y OIDC. Eso es lo mínimo. Las verdaderas preguntas son sobre la profundidad.
Tipos de grants: Cuáles y por qué importa#
Indispensables:
- Authorization Code + PKCE—El único flujo que debes usar para apps web y móviles. Si un proveedor aún recomienda el flujo Implicit, evítalo. PKCE no es opcional—es un requisito de seguridad.
- Client Credentials—Para comunicación servicio a servicio. Tu backend necesita autenticarse sin usuario presente.
- Refresh Token—Parece básico, pero los detalles varían enormemente. ¿Puedes configurar rotación? ¿Expiración? ¿Revocar un token específico sin terminar toda la sesión?
Cada vez más críticos:
- Token Exchange (RFC 8693)—Permite autenticación de agentes de IA, flujos de suplantación y delegación. Si falta hoy, consulta la hoja de ruta. Si no la tienen, es mala señal.
Capacidad de proveedor OIDC#
Pregúntate: ¿Puedes usar este IdP como proveedor OIDC—no solo como consumidor?
Por qué importa: A medida que tu SaaS crece, socios y clientes pueden querer usar tu sistema de identidad para acceder a sus propias herramientas. Debes emitir tokens, gestionar consentimientos y registrar apps de terceros. Si tu IdP solo consume proveedores externos y no puede actuar como uno, chocarás con un muro al federar hacia afuera.
Pregunta:
- ¿El IdP expone un endpoint de OpenID Discovery para personalizar marca?
- ¿Puedes registrar apps de primer y tercer nivel con distintos niveles de confianza?
- ¿Se puede omitir el consentimiento para apps de primer nivel y solicitarlo a las de terceros?
Personalización de JWT#
El token es el contrato entre tu IdP y tus servicios. Si no puedes personalizarlo, cada servicio debe hacer llamadas adicionales para saber lo que el usuario puede hacer.
Pregúntate:
- ¿Puedes añadir claims personalizados a tokens de acceso y de ID?
- ¿Puedes incluir el contexto de organización (en qué tenant opera el usuario) directamente en el token?
- ¿Puedes definir scopes personalizados que reflejen tu modelo de permisos?
- ¿Los claims se calculan al emitir el token o pueden poblarse dinámicamente vía webhook o script?
Un token con { "org_id": "org_123", "role": "admin", "auth_level": 2 } permite a tu middleware tomar decisiones en una línea. Un token con solo { "sub": "user_456" } exige que cada servicio consulte IdP o BD para resolver lo demás. A escala, esa diferencia son 2 ms frente a 200 ms por petición.
Dimensión 2: Flujos de autenticación—Los detalles que te matan#
Todos los IdP soportan email/password y social login. Felicidades, has filtrado... ninguno.
La diferenciación está en detalles que las demos no muestran.
El flujo de registro#
- Auto-login tras registro: ¿El usuario queda logueado tras registrarse, o ve de nuevo la pantalla de login? Obligarle a iniciar sesión tras el registro reduce drásticamente la conversión. Más IdP fallan en esto de lo que imaginas.
- Campos personalizados en registro: ¿Puedes recolectar rol, nombre de empresa o caso de uso al registrar? ¿O requieres un onboarding aparte?
- Perfilado progresivo: ¿Puedes pedir datos extra en varias sesiones, en vez de exigir todo de inicio?
El flujo de login#
- login_hint: ¿Puedes pre-llenar el email desde enlaces de campañas? Parece trivial, pero marca la diferencia entre 40% y 60% de conversión.
- Políticas de autenticación por organización: ¿Org A puede requerir SAML SSO y Org B email/password? ¿Puedes forzar MFA solo para tenants empresariales? Si necesita cambios de código y no de configuración, quemarás recursos en cada nuevo cliente.
- Personalización de marca: ¿Puedes personalizar UI por tenant? No solo logo y colores—CSS completo, dominios custom, emails de marca. La decisión entre Hosted UI y UI propia debe ser tuya, no una limitante del proveedor.
Lo que la mayoría omite#
- Autenticación silenciosa: Cuando expira un token, ¿la app puede refrescarlo sin redirigir? Si expira también el refresh, ¿hay fallback (p.ej. sesión deslizante vía iframe)?
- Vinculación de cuentas: Un usuario se registra con Google y luego intenta con email. ¿Son dos cuentas o una? ¿Cómo gestiona el IdP la fusión? Si está mal hecho, tendrás cuentas duplicadas para siempre.
- Opciones sin contraseña: Magic links, passkeys, WebAuthn. No porque hoy los necesites—tus clientes empresariales los pedirán en 6 meses.
Dimensión 3: Gestión de sesiones y tokens—Aguas profundas#
Aquí es donde separas la evaluación de la demo. Gestionar sesiones y tokens es aburrido hasta que falla—y cuando falla, todos tus usuarios quedan desloggeados de golpe.
Seguridad de cookies#
No es glamoroso, pero sí crítico.
- HttpOnly, Secure, SameSite: Los tres atributos deben estar bien. Cualquier IdP que no ponga HttpOnly está fuera de producción.
- Soporte para subdominios: Si tu app es
app.tuproducto.com y API api.tuproducto.com, ¿pueden compartirse las sesiones entre subdominios? ¿Cómo?
- Desaparición de cookies de terceros: Chrome las elimina. ¿Cómo maneja el IdP los flujos cross-origin sin cookies de terceros? Si la respuesta es "lo estamos trabajando", no es suficiente.
Recordar sesión y sesiones persistentes#
Tus usuarios quieren estar logueados semanas, no minutos. Pero sesiones de 180 días implican riesgos diferentes de una de 30 minutos.
Pregunta:
- ¿Puedes configurar duración de sesión distinta a la de los tokens?
- ¿Hay opción "recordarme" que extienda sesión pero acorte vida de tokens?
- ¿Puedes forzar reautenticación en operaciones sensibles sin terminar sesión?
Seguridad del refresh token#
- Rotación de tokens: ¿El IdP rota el refresh en cada uso? (Debe hacerlo.)
- Almacenamiento cifrado: ¿Los refresh tokens están cifrados en reposo?
- Revocación granular: ¿Puedes revocar la sesión de un solo dispositivo sin afectar otras?
- Expiración configurable: ¿Puedes fijarlo por app o solo es global?
Dimensión 4: Modelo de autorización—Más allá del RBAC básico#
El mínimo es Role-Based Access Control. Si el IdP no soporta RBAC, ni lo evalúes. Pero para SaaS B2B, RBAC no alcanza.
Permisos con alcance de organización#
Tus usuarios pertenecen a organizaciones. Sus permisos dentro de cada una son diferentes a los de la plataforma general.
Un usuario podría ser admin en Org A y solo visor en Org B. El mismo usuario, dos contextos de roles. Si el IdP no lo modela nativamente, tú montarás un sistema paralelo de permisos—tendrás dos fuentes de verdad.
Preguntas:
- ¿Puedes definir roles a nivel de organización, no solo de usuario?
- ¿Puede un usuario tener distintos roles en distintas organizaciones?
- ¿El contexto de organización se incrusta en el token para que tu API sepa en qué org opera?
Autorización multinivel (auth_level)#
Para aplicaciones financieras, de salud, o cualquier operación de riesgo: no todas las sesiones autenticadas son iguales.
¿Ves un dashboard? Una cookie basta. ¿Inicias una transferencia bancaria? Requiere MFA fresco aunque el usuario ya esté logueado.
Esto es autenticación escalonada (step-up), y exige tener nivel de autenticación (auth_level) como dato de primer nivel en el sistema de tokens.
Pregunta:
- ¿El token puede tener un claim
auth_level que tu backend lea?
- ¿Puedes disparar autenticación escalonada desde tu app sin re-login total?
- ¿El
auth_level expira independientemente de la sesión?
Si tu IdP no lo soporta, terminas construyéndolo tú mismo, precisamente lo que buscas evitar.
Autorización basada en tokens#
La idea: el middleware de tu API lee el token, ve organización, rol y auth_level, y autoriza, sin llamadas externas.
La realidad con muchos IdP: el token sólo te dice quién es el usuario y requieres otra API para saber permisos.
Esa llamada añade latencia, dependencias y otro posible fallo. A 1,000 peticiones por segundo, no quieres que la autorización haga saltos de red.
Dimensión 5: Migración—El criterio decisivo#
Un dato incómodo: la mayoría de evaluaciones IdP acaban no porque el nuevo IdP no sea suficiente, sino porque el equipo no puede migrar sus usuarios existentes.
Con más de 100,000 usuarios, migrar no es un “nice-to-have”—es TODO el proyecto.
Tres estrategias de migración (y cuál debe soportar IdP)#
1. Importación masiva con hashes de passwords ya calculados
Tus usuarios tienen passwords con bcrypt, argon2, lo que uses. ¿Puede el IdP importar esos hashes y verificarlos tal como están?
Si sí: el usuario entra con su contraseña de siempre, y nada cambia para él. El mejor escenario.
Si no: todos reciben email de “reestablece tu contraseña”. Perderás el 30–50% de tu base. No es teoría—lo hemos visto.
2. Migración progresiva (perezosa)
En vez de migrar de golpe, los migras uno a uno al loguearse: el primer login consulta tu viejo sistema, verifica el password, y crea el usuario en el nuevo IdP. El resto de logins ya usan el nuevo IdP.
Es la vía más segura a gran escala, pero el IdP debe permitir:
- Un hook de autenticación personalizado que consulte tu sistema antiguo
- Crear usuarios dinámicamente durante el login
- Rastrear quién está migrado y quién no
3. Escritura dual (sistemas en paralelo)
Durante la transición, ambos sistemas están activos. Se escribe en ambos, las lecturas pasan gradualmente al nuevo. Permite rollback pero complica operaciones.
Señales de alerta de migración#
- “Soportamos importación por CSV”—Sólo importa perfiles, no contraseñas. Igual pides restablecimiento.
- “Tenemos guía de migración”—Lee con atención; si dice que “los usuarios deben poner nueva contraseña”, estarás en el escenario de pérdida masiva de usuarios.
- Sin mención de compatibilidad de hashes—Si el proveedor nunca pensó en migración de hashes, no ha trabajado a tu escala.
Preguntas clave#
- ¿Qué algoritmos de hash soporta para importación? (bcrypt, argon2, scrypt, PBKDF2, ¿personalizado?)
- ¿Podemos hacer migración progresiva donde solo migran en su primer login?
- ¿Podemos rastrear el avance (% de usuarios ya migrados)?
- ¿Cuál es la estrategia de rollback si falla la migración?
- ¿Se puede mantener continuidad de sesión para no desconectar usuarios?
Si el proveedor no responde con seguridad, nunca lo ha hecho antes. Busca otro.
Dimensión 6: Multiarrendamiento—Nativo vs. añadido#
SaaS B2B significa multiarrendamiento. Tus clientes son organizaciones con usuarios, roles y políticas. El IdP debe entenderlo nativamente.
Qué es “multiarrendamiento nativo”#
- Organización como entidad de primer nivel: No como campo custom en el perfil, sino como modelo con ID propio, configuración y miembros.
- Políticas auth por organización: Org A usa SAML SSO con su IdP corporativo. Org B, email/password y MFA. Org C, Google Workspace. Todo configurable por UI o API, sin código.
- Gestión de invitaciones y membresía: Admins invitan, asignan roles y quitan miembros; el IdP gestiona invitación, verificación y asignación.
- Tokens con contexto organizacional: Cuando un usuario accede como organización, el token incluye ese contexto. Tu API sabe qué datos devolver.
Algunos IdP carecen de modelo de organización nativo. Sugieren usar metadata en el usuario (por ejemplo, user.app_metadata.org_id = "123").
Rápidamente falla:
- Un usuario en varias orgs: arrays en metadata
- Cero flujo de invitación / membresía embebido
- Sin políticas auth por organización
- Tokens sin contexto organizacional—debes inferirlo
- Logs de auditoría ignoran las organizaciones
Si te dicen “puedes modelar orgs con campos personalizados”, es equivalente a guardar relaciones en una columna JSON. Funciona hasta que deja de hacerlo.
Preguntas clave#
- ¿El modelo de organización es nativo o sobre metadata?
- ¿Usuarios pueden pertenecer a varias organizaciones a la vez?
- ¿Configuración de auth distinta por organización?
- ¿Roles y permisos por organización incluidos de forma nativa?
- ¿Admins de organización pueden gestionar miembros por UI autoservicio?
- ¿El token incluye el contexto organizacional?
Dimensión 7: Preparación para IA—El criterio aún no solicitado#
Hace un año, “autenticación de agentes de IA” no figuraba en la listas de evaluación. Hoy, si tu producto incluye features de IA—copilotos, agentes autónomos, workflows IA—tu IdP debe manejar un nuevo tipo de identidad: el agente.
Por qué los agentes rompen el modelo tradicional#
El auth tradicional tiene 2 actores: usuario y app. OAuth2 gira en torno a esto.
Los agentes IA meten un tercero: entidad no humana, actúa en nombre de usuario, permisos restringidos y pista de auditoría propia.
- Un agente no es usuario—no tiene sesión ni password
- No es máquina a máquina—actúa en nombre de un usuario concreto
- Requiere permisos acotados en tiempo y alcance, no todo el acceso del usuario
Qué debe soportar tu IdP#
Token Exchange (RFC 8693): El agente presenta su credencial más la autorización del usuario y recibe un token limitado. Este token lleva: quién (usuario), qué (agente), scope (frontera), cuándo (expira).
Agente como tipo de cliente: Modelado como cliente OAuth2 propio con client_id, no como hack de API keys o tokens compartidos.
Gestión de scope delegados: El usuario otorga permisos específicos al agente—lectura sin escritura, acceso solo a ciertos recursos.
Distinción en auditoría: Tus logs deben diferenciar “usuario hizo X” vs. “agente hizo X por el usuario”. Si no sabes esto, fallas SOC2: ¿quién cambió esto?
Compatibilidad con MCP (Model Context Protocol)#
MCP se está convirtiendo en el estándar para agentes IA. Si tu IdP soporta auth OAuth para servidores MCP, los agentes se autentican en capa protocolo—no por API keys o secretos compartidos.
Preguntas clave#
- ¿Soportan OAuth2 Token Exchange?
- ¿Se pueden modelar agentes como clientes distintos?
- ¿Los tokens llevan info de delegación (quién autorizó, scope)?
- ¿Los logs distinguen acciones de agente vs. humanas?
- ¿Integra servidor MCP o soporta OAuth para agent-to-tool?
Si no han pensado en esto, están construyendo para 2020 y tú para 2026.
Dimensión 8: Requisitos no funcionales—Lo que no te deja dormir#
Las funciones venden. Las operaciones deciden si renuevas.
Rendimiento#
- Throughput de autenticación: ¿Soporta 100+ auth/seg. en pico? ¿Y 1,000+?
- Latencia validando tokens: Si tus servicios validan JWTs localmente (deberían), es sub-milisegundo. Si exige introspección, ¿cuál es la latencia P99?
- Techo de escala: ¿Cuál es el máximo MAU soportado? ¿Hay historial operativo comprobado a tu escala?
Cumplimiento#
- SOC2 Tipo II: No Tipo I. La II implica haber sido auditado sostenidamente, no un día puntual. Si solo tienen Tipo I, pregunta cuándo esperan la II.
- Logs de auditoría: Cada evento, cambio de permiso y acción admin. ¿Puedes exportar a tu SIEM? ¿Son inmutables?
- Residencia de datos: ¿Puedes elegir la región de tu info? Para clientes EU, es obligatorio.
Fiabilidad#
- SLA de disponibilidad: 99.9% son 8.7h de caída/año. 99.99%, 52 min. Para auth—la puerta de tu app—la diferencia importa.
- Failover: ¿Qué pasa en caídas? ¿Hay fallback? ¿Multi-región?
- Historial de incidentes: Consulta su status page histórico. No lo que prometen, sino lo que ocurrió.
Portabilidad de datos#
- Exportación de usuarios: ¿Puedes exportar datos, metadata, membresías y roles? ¿Formato?
- Cumplimiento de estándares: ¿Usan protocolos estándar (OIDC, SCIM) para migrar con facilidad?
- No bloqueo: APIs propietarias, protocolos custom, formatos no estándar—señales de lock-in. Cuanto más propio, más difícil marcharte.
La matriz de evaluación: Un marco práctico de puntuación#
Tras evaluar todas las dimensiones, necesitas comparar. Aquí el marco de prioridad:
P1 — Rompedoras (criterios eliminatorios)#
| Criterio | Por qué es P1 |
|---|
| Importación de hashes o migración progresiva | Si no puedes migrar, no sirve |
| Authorization Code + PKCE | Seguridad mínima |
| Modelo de organización nativo | Esencial en SaaS B2B |
| SOC2 Tipo II o camino claro | Te lo exigirán los clientes |
| SLA 99.9%+ | Auth caído = producto caído |
P2 — Fuerte preferencia (si falta, gran esfuerzo de ingeniería)#
| Criterio | Por qué es P2 |
|---|
| Claims JWT personalizados | Evita lookups por cada petición |
| Políticas auth por organización | Onboarding empresarial |
| Roles/tokens con alcance org | Autorización multiarrendamiento |
| Rotación/revocación de refresh token | Mejores prácticas |
| Hosted UI + opción UI personalizada | Flexibilidad para casos distintos |
P3 — Importante (planifica para 12 meses)#
| Criterio | Por qué es P3 |
|---|
| Token Exchange (RFC 8693) | Auth de agentes IA |
| Capacidad de proveedor OIDC | Federación partners |
| Autenticación escalonada/auth_level | Operaciones críticas/riesgo |
| Aprovisionamiento SCIM | Sincronía de directorios clientes |
| Passkey / WebAuthn | Futuro sin contraseñas |
P4 — Nice to have (no bloquea decisión)#
| Criterio | Por qué es P4 |
|---|
| Dashboard analítico integrado | Se puede armar con logs |
| Emails white-label | Comodidad |
| Constructor visual de flujos | Comodidad |
| Conectores sociales prearmados (fuera top 5) | Proveedores minoritarios |
Cómo usar esto: Empieza por P1. Si un proveedor falla P1, deja de evaluarlo. Luego puntúa P2 y P3. El proveedor con mejor suma P2+P3 es tu respuesta.
Errores comunes en la evaluación#
Los equipos cometen los mismos errores una y otra vez. Cómo evitarlos:
Error 1: Evaluar por funciones, no por arquitectura#
Una tabla dice lo que hay. No cómo se construyó. Un IdP podría “soportar” organizaciones solo guardando IDs en la metadata. Marca la casilla en Excel pero da problemas reales en producción.
Solución: Para cada función, pregunta “¿cómo se implementa?”—no solo “¿la tienes?”
Error 2: Ignorar migración hasta después de seleccionar#
Eligen el IdP “mejor”, empiezan la implementación, y luego ven que no pueden migrar sin restablecer contraseñas. Ahora están atados a una mala experiencia o empiezan de nuevo.
Solución: Haz de la migración tu primer filtro, no el último.
Error 3: Sobrevalorar la demo#
Todas las demos son pulidas. Muestran el camino feliz, cero casos raros. Tu producción tiene usuarios fusionados, unicode extraño y sesiones anómalas.
Solución: Pide prueba de concepto con tus datos reales. Importa 1,000 usuarios reales y prueba tus flujos.
Error 4: No involucrar a los indicados#
Si solo evalúa el equipo plataforma, elige por limpieza técnica. Si solo producto, integración fácil. Si solo seguridad, sólo compliance.
Solución: Incluye plataforma, producto y seguridad en el equipo evaluador. Cada uno es dueño de criterios P1/P2.
Error 5: Olvidar que en algún momento tendrás que migrar#
El lock-in existe. SDKs propietarios, APIs custom y tokens no estándar hacen más difícil salirte después.
Solución: Prefiere IdP con protocolos estándar (OIDC, OAuth2, SCIM). Tu futuro yo lo agradecerá.
Preguntas frecuentes#
¿Cuánto suele durar una evaluación de IdP?#
Para una evaluación a fondo con prueba de concepto, cuenta con 4-8 semanas. Acelerar conlleva errores, sobre todo olvidando la migración. Calcula: 2 semanas recolección de requerimientos, 2-3 de evaluación y PoC, 1-2 para alinear stakeholders.
¿Deberíamos construir auth propio?#
Depende de tu etapa. Si tienes menos de 10k usuarios y nada de clientes empresariales, una librería ligera podría valer. Pero si necesitas SSO, multiarrendamiento, MFA y compliance, el coste de mantener auth propio supera a un IdP. Hemos visto equipos perder 2-3 ingenieros FTE solo en auth—año tras año.
¿Diferencia entre CIAM y workforce IAM?#
CIAM (Customer Identity & Access Management) es lo que usan tus usuarios finales—registro, login, perfil. Workforce IAM es para tus empleados y acceso interno (Okta con Slack, Google Workspace, etc.). Compras y criterios distintos. Esta guía cubre CIAM.
¿Qué tan clave es open-source vs. propietario?#
Open-source da transparencia (puedes auditar), portabilidad (self-host si hace falta) y comunidad. Los propietarios pueden tener mejores UIs y servicio gestionado. La cuestión no es “¿libre o cerrado?” sino “¿puedo irme si quiero?” El open-source casi siempre lo facilita pues APIs y modelos son públicos.
¿Cuándo la autenticación de agentes de IA pasa de P3 a P1?#
Si ya tienes features IA accediendo a datos de usuarios (copilotos, workflows, asistentes), ponlo como P1 ya. Si IA está en tu hoja a 6-12 meses, mantenlo en P3 pero dale peso. Si la IA no está en tus planes, déjalo P4—pero revisa en 6 meses.
¿Cómo comparar precios entre modelos distintos?#
Casi todos IdP cobran por MAU. Pero "MAU" varía: algunos por login, otros por usuarios únicos, otros cuentan tokens M2M aparte. Pide presupuesto según tu escenario real: X usuarios, Y organizaciones, Z conexiones M2M y tu volumen esperado. Compara coste total, no solo unitario.
Conclusión#
Elegir un proveedor de identidad es una decisión infraestructural, no funcional. Comprometes un sistema que gestionará cada interacción de usuario, cada control en tu API y cada entrada de log para compliance.
El marco anterior cubre lo que realmente importa—no el marketing. Úsalo para filtrar candidatos rápido (criterios P1), evaluar a fondo (P2 y P3 con PoC) y tomar una decisión sostenible.
Los equipos que lo logran tienen algo en común: tratan la identidad como infraestructura, no como feature para entregar y olvidar.
