Gerege SSO

Production · Capa 2 — Autenticación / SSO · Repositorio: sso-gerege-mn · sso.gerege.mn

El proveedor OAuth2 / OpenID Connect de la línea del sector privado. Aquí es donde las aplicaciones del ecosistema y las relying parties (RP) de terceros dan acceso a los ciudadanos.

El Gerege SSO sobre Nexus es otra cosa

En agosto de 2026 se forkeó desde Gerege Nexus un repositorio nuevo llamado sso-gerege-nexus, que también se llama «Gerege SSO». El comportamiento descrito en esta página corresponde al código sso-gerege-mn que corre en producción. El fork nuevo aún no tiene dominio propio, así que el contrato de sso.gerege.mn no ha cambiado: los RP no tienen que ajustar nada.

Tres funciones

1. Proveedor de identidad

Los RP pueden ofrecer Sign in with Gerege. Lo que se admite:

Capacidad	Nota
Authorization code + PKCE (S256)	El flujo principal; seguro incluso para clientes públicos
Refresh token rotatorio	Con detección de reutilización — reutilizar un token viejo invalida toda la cadena
client_credentials	Integración máquina a máquina
Access token	Opaco — su contenido no es visible para el RP
id_token	JWT firmado con RS256
Discovery	/.well-known/openid-configuration
UserInfo	/userinfo

2. Proxy de eID

Las aplicaciones nunca acceden directamente a eID Mongolia. El SSO hace de proxy de los servicios eID autorizados y los entrega solo a aplicaciones registradas.

El motivo: así las credenciales de eID viven en un único lugar y el rastro de auditoría forma una sola cadena. Repartir credenciales de eID a cada aplicación haría imposibles la rotación, la revocación y el seguimiento de quién hizo qué.

3. El único lugar donde se registran aplicaciones

Los clientes OAuth y sus secretos se crean solo aquí y solo aquí se guardan. Ni siquiera el Developer Portal crea clientes: se limita a explicar qué hacer y a enlazar en profundidad con la consola del SSO.

¿Por qué un único lugar?

Si las credenciales viven a la vez en dos sistemas, tarde o temprano divergen: un cliente borrado en un lado sigue funcionando en el otro, una rotación de secreto nunca llega al otro lado, y así sucesivamente. No hay alternativa fiable a una única fuente.

Métodos de acceso

Método	Nota
eID	El método principal — código QR / deep link móvil / push por número de registro
Google	Secundario — el primer enlace exige verificación por eID para vincularlo a una persona real

No hay contraseñas. Tampoco acceso por correo/OTP. Es una decisión deliberada: una contraseña que no existe no puede filtrarse.

Servicios adyacentes

Las pasarelas relacionadas que funcionan desde el mismo repositorio:

• DAN Gateway

  ---

  dan.gerege.mn — la pasarela de identificación DAN.

• G-Sign

  ---

  gsign.gerege.mn — la pasarela de firma.

• Gerege Verify

  ---

  xyp.gerege.mn — consultas al registro de personas jurídicas.

Sesión y cierre de sesión

• Una sesión es un par JWT access + refresh; el refresh rota.
• El cierre de sesión invalida tanto el refresh como el access (deny-list de access).
• Tras cerrar sesión, la persona vuelve al dominio desde el que empezó; no se la lanza a /login. Esta regla no rompe el flujo de usuario del RP.

Un poco de historia arquitectónica — dejar Hydra

El SSO usaba antes Ory Hydra como proveedor OIDC. Esa dependencia se ha eliminado por completo y los mecanismos necesarios se reescribieron como código Go propio (usecases/oidc). La base de datos separada de Hydra se fusionó con la principal.

El resultado:

• una dependencia externa menos,
• dos bases de datos y dos cadenas de migración convertidas en una,
• el comportamiento OIDC queda bajo control propio (en particular, puede acoplarse estrechamente al flujo de eID).

El mismo código que la plataforma

El SSO no es un sistema escrito aparte: funciona exactamente sobre la misma base de código que la plantilla de plataforma. La única diferencia es un ajuste: con AUTH_MODE=provider la tarjeta de acceso se muestra aquí; con client se redirige a un SSO superior. La misma imagen de Docker arranca en cualquiera de los dos papeles.

Más: Código compartido · Autenticación y autorización.

Integrarse (ser un RP)

Pasos generales:

1. Registrar la aplicación — crear un cliente en la consola del SSO y obtener client_id / client_secret. Registrar los redirect URI con exactitud.
2. Leer el discovery — tomar los endpoints de /.well-known/openid-configuration.
3. Implementar authorization code + PKCE.
4. Intercambiar el token — code → access + refresh + id_token.
5. Validar el id_token — firma RS256, iss, aud, exp.
6. Obtener los datos del usuario — /userinfo.

Para el flujo detallado y una lista de comprobación, consulte Autenticación y autorización.

Registre los redirect URI con exactitud

El error más común en OIDC. Un redirect URI debe coincidir carácter por carácter: importan la / final, http frente a https y el puerto. Si olvida actualizar esta lista al cambiar de dominio, el acceso fallará en silencio.

Documentación detallada

La documentación a nivel de implementación (esquemas de endpoints, modelo de base de datos, guía de administración para el registro de RP) vive dentro del repositorio sso-gerege-mn.