WKID revive BrowserID: autenticación sin Google para founders

¿Qué fue BrowserID y por qué desapareció?

En 2016, Mozilla discontinuó BrowserID (también conocido como Mozilla Persona), un sistema de autenticación federada que permitía a los usuarios iniciar sesión en cualquier sitio usando solo su email, sin depender de Google o Facebook. La promesa era poderosa: privacidad, control del usuario y soberanía de identidad. Sin embargo, el proyecto no logró adopción masiva y fue cerrado.

El fracaso de BrowserID no fue técnico, sino de ecosistema. Los grandes proveedores ya habían establecido OAuth como estándar, y los desarrolladores priorizaron la conveniencia sobre la privacidad. Hoy, más de 8 años después, un desarrollador está reviviendo esta idea con un enfoque diferente: WKID, un servidor de identidad diseñado no para conquistar el mundo, sino para proyectos personales y familiares.

¿Por qué WKID funciona donde BrowserID fracasó?

La clave está en el alcance. BrowserID intentaba reemplazar a Google Auth y Facebook Login a nivel global. WKID, en cambio, se enfoca en un nicho específico: desarrolladores que quieren autenticación federada para sus propias apps sin depender de terceros. Este cambio de perspectiva es fundamental.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Con la llegada de las LLMs en 2025-2026, desarrollar sistemas de autenticación personalizados se ha vuelto significativamente más accesible. Lo que antes requería un equipo de seguridad dedicado, ahora puede ser implementado por un founder técnico en días, no meses. WKID aprovecha esta realidad: usa emails de dominios propios como identidad, evitando problemas de cookies de terceros que están eliminándose progresivamente.

El contexto actual: privacidad, cookies y soberanía de datos

En 2026, el panorama de la autenticación ha cambiado drásticamente. Las cookies de terceros están siendo eliminadas por Chrome, Safari y Firefox. Las regulaciones de privacidad en Europa (GDPR) y Latinoamérica se han endurecido. Los founders enfrentan un dilema: depender de proveedores externos que pueden cambiar sus términos (como hizo Meta con sus APIs) o construir sistemas propios que mantengan el control de los datos de usuarios.

Además, han surgido alternativas modernas como Auth0, Clerk, Supabase Auth y Firebase Auth, que ofrecen autenticación gestionada pero con costos que escalan rápidamente. Para un SaaS en etapa temprana, estos servicios pueden representar un gasto significativo cuando el producto aún no genera ingresos consistentes.

¿Qué significa esto para tu startup?

Si estás construyendo un SaaS, una app familiar o un proyecto con usuarios limitados, esta aproximación tiene implicaciones directas para tu estrategia técnica y de negocio:

1. Evalúa tu dependencia de proveedores externos

Pregúntate: ¿qué pasaría si Google cambia sus términos de OAuth mañana? ¿Si Auth0 duplica sus precios? Tener control sobre tu sistema de autenticación reduce el riesgo operacional. Para proyectos pequeños, una solución como WKID puede ser más sostenible que pagar por servicios gestionados.

2. Acciones concretas que puedes implementar

Audita tu stack de autenticación actual: Lista todos los proveedores externos de los que dependes (Google, Facebook, Auth0, etc.) y calcula el costo mensual. Si supera el 5% de tu MRR, considera alternativas propias.
Prueba WKID o similares para proyectos internos: Antes de migrar tu producto principal, implementa un sistema de identidad basado en email para herramientas internas o betas cerradas. Esto te da experiencia sin riesgo.
Documenta tu propia política de identidad: Define claramente cómo manejas los datos de usuarios, dónde se almacenan y quién tiene acceso. Esto es crucial para compliance con GDPR y regulaciones latinoamericanas emergentes.
Considera híbridos: No tiene que ser todo o nada. Puedes ofrecer login con email propio como opción primaria, manteniendo OAuth como fallback para usuarios que lo prefieran.

Cuando NO usar autenticación personalizada

Es importante ser realista: WKID y enfoques similares no son para todos los casos. No los uses si:

Tu producto requiere escala global desde el día uno
Necesitas verificación de identidad avanzada (KYC, 2FA obligatorio)
Tu equipo no tiene capacidad técnica para mantener el sistema
Estás en un sector regulado (fintech, healthtech) que requiere certificaciones específicas

En esos casos, proveedores como Auth0 o Clerk siguen siendo la mejor opción, a pesar del costo. La soberanía tiene un precio: mantenimiento, seguridad y responsabilidad.

Lecciones del ecosistema hispanohablante

En LATAM y España, hemos visto startups que dependen excesivamente de infraestructura externa. Cuando los precios suben o los servicios cambian, el impacto es directo en el runway. La tendencia hacia no-code y automatización ha hecho que muchos founders prioricen velocidad sobre control, pero en 2026 el péndulo está volviendo.

Startups españolas como Groove y mexicanas como Clip han invertido en infraestructura propia desde etapas tempranas, lo que les dio flexibilidad para escalar sin renegociar contratos constantemente. No se trata de rechazar servicios externos, sino de elegir estratégicamente dónde mantener control.

Conclusión

Revivir BrowserID en 2026 no es nostalgia tecnológica: es una respuesta pragmática a un ecosistema donde la privacidad, el costo y el control son factores críticos para founders. WKID demuestra que las ideas "fallidas" del pasado pueden tener éxito cuando se recontextualizan para un nicho específico y se aprovechan las herramientas actuales.

Para tu startup, la pregunta no es "¿debería construir mi propio sistema de autenticación?" sino "¿qué nivel de control necesito sobre la identidad de mis usuarios, y qué estoy dispuesto a sacrificar por ello?". La respuesta dependerá de tu etapa, tu equipo y tu visión de largo plazo.