SSO sin contraseña con Notakey: guía de configuración paso a paso

Al terminar esta guía, sus usuarios iniciarán sesión en una aplicación aprobando desde el teléfono: escriben un nombre de usuario, o escanean un código QR, y confirman en la app de Notakey. Sin contraseña en la pantalla de inicio de sesión. La contraseña sigue existiendo, pero cumple una única función obligatoria: se pide una vez, al registrar el dispositivo, para generar la clave del usuario. Todo lo que viene después es una decisión de política, y esta guía indica exactamente dónde se configura cada una.

Cualquier servicio de Notakey —los mismos que ya usa para 2FA en VPN, Windows o Wi-Fi— puede actuar también como proveedor de OpenID Connect. No hace falta un producto aparte: active OIDC para un servicio desde el Dashboard, registre la aplicación que lo usará como cliente y apunte esa aplicación a los endpoints que Notakey le entrega. Sin certificados SAML, sin un servidor de identidad independiente que mantener.

your app ──OIDC──▶ Notakey service (OIDC provider)
                        │
                        ├──▶ user repository: onboarded devices in this service
                        └──▶ push ──▶ user's phone: read, approve

(Las aplicaciones empresariales clásicas que solo hablan SAML —Google Workspace, AWS— necesitan en cambio el proveedor de identidad SAML independiente de Notakey; la última sección indica dónde encontrarlo.)

Cómo funciona aquí realmente la contraseña

Vale la pena ser precisos, porque «sin contraseña» se usa a menudo como término vago:

La contraseña obligatoria es solo la del alta. Se define en el Dashboard o se toma de Active Directory, y se comprueba una única vez cuando el usuario registra su dispositivo y se genera su clave en el hardware seguro del teléfono.
El inicio de sesión diario no tiene ninguna. El usuario escribe un nombre de usuario o escanea un código QR; la pantalla de inicio de sesión puede reducirse a un simple escaneo, sin ningún campo en el que escribir. La comprobación de identidad es la aprobación firmada en la app.
Todo lo demás es un ajuste, no una norma fija. Una app puede pedir una confirmación adicional dentro de la propia app, otra una contraseña, una tercera ambas cosas. También puede volver a pedirse la contraseña cada cierto intervalo, solo para que nadie la olvide del todo. Todo se configura en una única pantalla, que se explica en el paso 5.

Paso 1 — Elija un servicio

Use un servicio de Notakey existente si sus usuarios ya coinciden con los de la aplicación que va a conectar, o cree uno nuevo (Services → Manage → New) si quiere que esta app tenga su propia política de contraseña, independiente de todo lo demás. La política del paso 5 se aplica a todo el servicio, no por cliente — ese es el criterio que decide.

Paso 2 — Active OpenID Connect

Abra el servicio y vaya a OpenID Connect configuration → Configure; marque Enabled. Deje el resto con sus valores por defecto por ahora — Require password y Require mfa se configuran de forma deliberada en el paso 5, no aquí por descuido. Guarde.

Paso 3 — Copie los endpoints

De vuelta en OpenID Connect configuration, haga clic en Show. Notakey ya ha generado un documento de descubrimiento y los endpoints individuales que hay detrás:

https://<your-dashboard-host>/oidc/services/<access-id>/.well-known/openid-configuration

La mayoría del software compatible con OIDC solo necesita esta URL: péguela en un campo «auto discovery» o «issuer» y la app obtiene por sí sola los endpoints de autorización, token, userinfo y JWKS. <access-id> es el mismo ID que aparece en la propia página del servicio.

Paso 4 — Registre la aplicación como cliente

Dentro del servicio, vaya a OpenID Connect configuration → Clients → New client. Notakey genera automáticamente un Client ID y un Secret aleatorio.

Dos cosas conviene saber antes de guardar: el campo Secret está enmascarado y Notakey no volverá a mostrárselo una vez que salga de la página, así que cópielo ahora — o bien seleccione el campo y pegue un secreto propio, que funciona igual de bien y es más fácil de controlar. Y el campo Redirect URIs tiene que coincidir carácter por carácter con la URL que la app devuelve durante el inicio de sesión — una barra final que la app no envía basta para romperlo (vea el problema típico más abajo).

Complete:

Description — cualquier texto que le ayude a reconocerlo más adelante.
Secret — copie el generado, o sustitúyalo por uno propio.
Redirect URIs — la URL de callback OAuth de la app. Sepárelas con comas si la app es accesible desde varias direcciones.
Logout URI — a dónde redirigir el navegador tras cerrar sesión. Opcional.

Una vez registradas un par de aplicaciones, la lista de clientes del servicio tiene este aspecto:

Paso 5 — Apunte la app a Notakey

Los pasos exactos dependen de la app, pero el patrón es siempre el mismo: una URL de issuer o descubrimiento, un client ID y un client secret. Dos ejemplos reales con herramientas autoalojadas:

Gitea trae un comando de CLI para esto — sin formulario web, sin reinicio:

gitea admin auth add-oauth \
  --name notakey \
  --provider openidConnect \
  --key <client-id> \
  --secret <client-secret> \
  --auto-discover-url https://<dashboard-host>/oidc/services/<access-id>/.well-known/openid-configuration \
  --scopes openid --scopes profile --scopes email

La pantalla de inicio de sesión de Gitea añade de inmediato un botón «Sign in with notakey», junto al formulario de contraseña ya existente — no se elimina nada.

Proxmox VE lo trata como un realm de autenticación adicional, que convive con los que ya existan:

pveum realm add notakey --type openid \
  --issuer-url https://<dashboard-host>/oidc/services/<access-id> \
  --client-id <client-id> \
  --client-key <client-secret> \
  --username-claim sub \
  --scopes "openid email profile" \
  --autocreate 1

Aquí --issuer-url es la URL de descubrimiento sin el sufijo /.well-known/openid-configuration — Proxmox lo añade por su cuenta. --autocreate 1 crea el usuario de Proxmox correspondiente en el primer inicio de sesión correcto, sin ningún permiso hasta que usted se los conceda de forma explícita; no va a repartir acceso por descuido.

Paso 6 — Configure la política de contraseña

Aquí es donde la «decisión del administrador» se vuelve concreta, de nuevo en OpenID Connect configuration → Configure:

Require password sin marcar, con Require mfa marcado: el flujo sin contraseña descrito al principio de esta guía. El inicio de sesión es nombre de usuario (o QR) más aprobación desde el teléfono, y nada más.
Require password marcado y Password cache en 0: contraseña en cada inicio de sesión, además de la aprobación — el clásico segundo factor.
Require password marcado con un Password cache en segundos (por ejemplo, 2592000 para 30 días): sin contraseña en el día a día, y se vuelve a pedir una vez transcurrido ese plazo — únicamente para que no caiga en el olvido. Mfa cache funciona igual para el paso de aprobación, si alguna vez quiere cachear también eso.

Como este ajuste es válido para todo el servicio, una app que necesite una política distinta a la de sus vecinas debería vivir en su propio servicio — de vuelta a la decisión del paso 1.

Cuando algo no funciona

Un error de redirect_uri mismatch casi siempre es cuestión de una barra final: unas apps envían https://app.example.com, otras https://app.example.com/, y Notakey compara la cadena de forma exacta. Revise los logs de acceso de nginx o de la app para ver el redirect_uri= literal que envió, y registre ese valor tal cual.
Si la URL de descubrimiento devuelve 404, compruebe que Enabled realmente se guardó en el paso 2 — una pantalla de configuración que parece correcta pero nunca se envió es el descuido más habitual.
El registro Authentication activities del servicio muestra todos los intentos que llegaron a Notakey. Un intento que no aparece ahí significa que la app nunca llegó al endpoint de autorización — revise primero el client ID y la URL de descubrimiento.

Lo que esta guía deja fuera a propósito

Las integraciones SAML 2.0 clásicas para apps que solo hablan SAML —Google Workspace, AWS y similares— pasan por el proveedor de identidad SAML independiente de Notakey, no por el camino OIDC descrito aquí. LDAP/Active Directory como repositorio de usuarios, las configuraciones multiinquilino y la personalización de marca tampoco entran en esta guía. Todo eso está en la referencia de CLI y API, con tablas completas de parámetros; esta guía es el camino rápido de cero a un inicio de sesión sin contraseña funcionando.

Véalo antes de construirlo

La forma más rápida de valorar la experiencia de inicio de sesión es probar usted mismo el flujo de aprobación: pruebe la demo en vivo y firme una solicitud desde su teléfono en unos dos minutos, o solicite una demostración y trazaremos el camino desde sus aplicaciones y su política de contraseña hasta un piloto en su propia infraestructura.