Siempre soñé con que me pagaran por escribir y mantener open source. En enero de 2025, eso se hizo realidad cuando me uní al equipo de authentik, un Identity Provider open source moderno que soporta SAML, OAuth2/OIDC, LDAP, RADIUS y más. En este tiempo aporté nuevas funcionalidades, mejoras de UX, corrección de bugs, documentación y mantenimiento de dependencias.

authentik une varias de mis pasiones: el open source, la seguridad y la experiencia de usuario. Mi experiencia con IdPs era bastante limitada, más bien por un background en consultoría de seguridad y pentesting. De protocolos había implementado OAuth2 en un par de proyectos, incluyendo una integración de autenticación OAuth2.0 entre un sistema legacy y BigCommerce en Snap Kitchen, pero trabajar en el núcleo de un Identity Provider era territorio nuevo. Y resultó ser exactamente donde quería estar :)

El mejor proceso de hiring que viví

Antes de hablar de código, quiero hablar del proceso de contratación, porque dice mucho sobre la cultura del equipo. Fue el mejor que viví en mi carrera: Completé un Google form, una entrevista con el CEO (Fletcher Heisler), otra con el CTO (Jens Langhammer), y listo, me propusieron un contrato de 4 semanas de prueba para ver cómo trabajábamos juntos. Mi CV, mi GitHub y las entrevistas demostraban que la experiencia estaba. Nada de pruebas de LeetCode que no tienen nada que ver con el trabajo real.

Mi tarea de prueba fue un feature request que la comunidad venía pidiendo desde 2022.

Email OTP: mi primer desafío y prueba de fuego

El Email Authenticator Stage, un sistema completo de autenticación multifactor por correo electrónico, fue mi tarea de ingreso. El issue llevaba abierto desde 2022 y era una funcionalidad muy solicitada: no todos los usuarios tienen acceso a apps de TOTP o a llaves de seguridad, y el email es una alternativa accesible que muchas organizaciones necesitan.

El desarrollo incluyó el stage completo (una app de Django), la integración con el flow engine de authentik, la UI en Lit.js, la documentación y los tests. Fueron varias semanas desde el primer commit hasta tenerlo estable (+3,286 -18). Pero el desafío mayor fue entender todo el sistema y cómo cada parte se conecta con otra, por suerte tuve muchísimo feedback y ayuda de parte del equipo.

Y como no podía ser de otra manera, pagando derecho de piso, rompí el envío de mails desde authentik 🤦🏻‍♂️. Había un bug de serialización en el email stage que no sucedía en dev, solo en entornos de producción cuando la tarea se serializaba para enviar al worker, pero sacamos un patch bastante rápido y la crisis fue resuelta.

A raíz de esto me convertí no oficialmente en el "email guy" y tuve que resolver varios bugs relacionados con el envío de correos. El más divertido fue otro bug de serialización en el email stage que me tomó varias iteraciones: el problema aparecía cuando el nombre del remitente contenía caracteres en cirílico, un caso edge sutil que rompía la serialización de formas inesperadas.

Algunos features que implementé

Password Uniqueness Policy: seguridad enterprise

Implementé una política de unicidad de contraseñas (enterprise), que permite a los administradores configurar que los usuarios no puedan reutilizar contraseñas anteriores. Es una funcionalidad estándar en entornos corporativos donde las políticas de compliance exigen la rotación de contraseñas sin repetición.

La cantidad de contraseñas anteriores contra las que se compara es configurable. Los hashes de contraseñas anteriores se almacenan de forma segura en la base de datos de authentik y la política se integra directamente en el flujo de cambio de contraseña, de forma transparente para el usuario.

OAuth2/OIDC Back-Channel Logout: probablemente el feature más complejo

Este fue probablemente el feature más complicado en el que trabajé, y con mucho impacto. authentik ya contaba con uno de los mejores soportes OAuth2/OIDC del mercado, pero faltaba el back-channel logout, una especificación bastante nueva que permite que cuando un usuario cierra sesión, se notifique automáticamente a todas las aplicaciones conectadas para que invaliden sus sesiones. Un cierre de sesión verdaderamente global.

Lo que hizo este desarrollo especialmente desafiante fue lo nuevo del estándar: la gran mayoría de los IdPs no lo soportaban al momento de la implementación, incluidos big players como Okta. Esto también significó que probarlo con aplicaciones reales fue difícil, porque pocas lo soportan del lado del Service Provider. Lo probamos con Matrix Synapse y con Keycloak (que también es un excelente IdP open source), entre otros.

Escribimos un post con los detalles de la implementación.

Passkey Autofill: cuando UX y seguridad se encuentran

Entre las cosas que más me gustaron de trabajar en authentik fue poder implementar features que mejoran la experiencia de usuario sin sacrificar seguridad. El Passkey Autofill es un ejemplo perfecto de esto. Implementé el soporte para WebAuthn Conditional UI, más conocido como passkey autofill. Esto permite que en el stage de identificación el navegador sugiera automáticamente las passkeys disponibles, similar a como el autocompletado sugiere contraseñas guardadas, pero para passkeys.

Lo uso en mi día a día en mi propia instancia de authentik y creo que es uno de esos features donde UX y seguridad hacen que la vida del usuario sea más fácil y más segura al mismo tiempo. El login passwordless con passkey autofill es extremadamente conveniente.

Un aprendizaje interesante de este feature fue el problema de descubrimiento. WebAuthn es el nombre técnicamente correcto del estándar, pero la mayoría de los usuarios no sabe qué es. Lo que sí conocen son "passkeys", "security keys", "Yubikeys" o "FIDO2". Es un problema real de la industria: la cantidad de términos y acrónimos hace que los usuarios no encuentren lo que buscan. Trabajé bastante en la documentación y en lo que se podría considerar SEO para asegurar que los usuarios pudieran encontrar estas funcionalidades con los términos que realmente usan.

Más allá del código: documentación, UX y algunos detalles que importan

No todo el trabajo que importa aparece en las release notes. Dedicé bastante tiempo a mejoras pequeñas que surgieron de ver cómo los usuarios realmente usaban el producto: búsqueda case-insensitive porque la gente no siempre recuerda cómo escribió algo, links a la documentación en contexto porque nadie debería tener que buscar en Google desde adentro de la UI, mensajes de error más claros que guíen al usuario. El caso del passkey autofill me lo enseñó claramente: el feature estaba, pero si el usuario no lo encuentra porque lo llama "passkey" y vos lo llamás "WebAuthn", es casi como si no existiera.

También estoy orgulloso de las contribuciones a la documentación, porque sin buenos docs los usuarios no pueden usar las funcionalidades. Un feature de seguridad que nadie usa por ser complicada o por no tener documentación, simplemente no sirve. En Authentik aprendí muchísimo sobre cómo escribir documentación técnica, gracias a la calidad de la documentación del proyecto y al equipo (¡gracias, Tana!).

La parte invisible: mantenimiento y estabilidad

Una parte importante del trabajo fue el mantenimiento de dependencias: más de 330 actualizaciones de paquetes Python durante el año (dependabot no funcionaba muy bien al principio con uv como package manager). También trabajé en varios upgrades de Django (5.0 -> 5.1 -> 5.2) que necesitaron mucho trabajo, inclusive forkear algunas dependencias para poder avanzar.

También fui release manager de las versiones 2025.4 y 2025.12, pero esto merece un post aparte.

El proceso: rigor, transparencia y colaboración

El proceso de code review en authentik es riguroso y colaborativo. Casi todo sucede en GitHub, por practicidad y por transparencia hacia la comunidad, aunque a veces necesitamos llamadas 1:1, pair programming o discusiones con todo el equipo.

La seguridad es innegociable, al igual que las buenas prácticas. Varios pull requests toman semanas de review riguroso pero amigable. Tuve PRs rechazados, algunos fueron prototipos (un PR es la mejor forma de vender una idea al equipo) y otros chocaron con problemas que ocurrieron en el pasado con approaches similares. No conocer el "lore" de authentik fue un desafío al principio, pero eso es parte del aprendizaje.

Al ser un proyecto open source, cualquiera puede aportar en los PRs. Suelo pedirles colaboración a los usuarios afectados para probar los parches, ya sea en los issues de GitHub o en el Discord de la comunidad. Varios de mis compañeros actuales fueron contratados de la comunidad porque conocían el producto y lo usaban diariamente en sus homelabs o en sus trabajos.

El equipo y la experiencia más allá del código

No puedo hablar de mi experiencia en authentik sin hablar del equipo. Son personas extremadamente talentosas técnicamente y con una calidez humana real, una combinación que no siempre se da en la industria. Sentir que uno puede seguir aprendiendo todos los días no tiene precio.

En 2025 tuve la oportunidad de representar a authentik como sponsor en DEFCON y DjangoCon, atendiendo el stand junto a varios compañeros. En la DjangoCon además di una lightning talk sobre back-channel logout, presentando en vivo el feature en el que había trabajado. Estar del otro lado, explicándoles a otros desarrolladores por qué esto importa y viendo sus reacciones, fue una experiencia muy distinta a escribir el código.

El momento más especial fue el company retreat en Francia, donde nos encontramos presencialmente por primera vez. Cada uno de un lugar distinto del mundo, y hasta ese momento toda nuestra colaboración había sido remota. Ponerle cara y personalidad a las personas con las que venís trabajando día a día cambia la dinámica por completo.

Lo que aprendí

Contribuir a authentik me dio la oportunidad de trabajar en un stack completo y diverso: Python con Django en el backend, TypeScript con Lit.js en el frontend y Go en los outposts. Aprendí mucho sobre protocolos de identidad (OAuth2, SAML, WebAuthn), sobre cómo diseñar sistemas de autenticación flexibles a través del flow engine, y sobre algo que no es tan técnico pero igual de importante: pensar a futuro. Una solución tiene que ser buena en el tiempo y no solo para resolver el problema actual. Nada de quick patches.

El trabajo en open source te obliga a pensar en la documentación, en los edge cases, en la retrocompatibilidad y en que tu código va a ser leído y usado por personas que no conocés. Eso, yo creo que te hace un mejor desarrollador.

¿Y ahora?

Lo que sí, a corto plazo, gracias a authentik, voy a dar una charla con Fletcher, mi jefe, en San Francisco, California, en la conferencia de seguridad BSidesSF. Está de más decir que estoy muy emocionado por eso.

Si bien es imposible saber todo lo que depara el futuro, todos los indicios son bastante positivos. Sobre todo, el sentirse realizado con el trabajo que uno hace es extremadamente satisfactorio. Sé que estoy exactamente donde quiero estar :)

¿Querés contribuir?

Si estás pensando en contribuir a authentik, mi consejo es simple: usá el producto. Aprendé cómo funciona, identificá qué se podría mejorar para tu caso de uso. Los mejores contribuidores y varios de mis compañeros empezaron exactamente así.

Podés encontrar el proyecto en GitHub, unirte al Discord de la comunidad y empezar a explorar los issues abiertos. Y si la identidad, la seguridad y el open source son tu combinación ideal, como lo son para mí, quizás este sea tu próximo proyecto.