Gerege SSO

Production · Couche 2 — Authentification / SSO · Dépôt : sso-gerege-mn · sso.gerege.mn

Le fournisseur OAuth2 / OpenID Connect de la ligne du secteur privé. C'est ici que les applications de l'écosystème et les relying parties (RP) tierces authentifient les citoyens.

Le Gerege SSO sur Nexus est autre chose

En août 2026, un nouveau dépôt nommé sso-gerege-nexus a été forké depuis Gerege Nexus ; il s'appelle lui aussi « Gerege SSO ». Le comportement décrit sur cette page est celui du code sso-gerege-mn en production. Le nouveau fork n'a pas encore de domaine propre : le contrat de sso.gerege.mn est donc inchangé et les RP n'ont rien à modifier.

Trois rôles

1. Fournisseur d'identité

Les RP peuvent proposer Sign in with Gerege. Ce qui est pris en charge :

Capacité	Remarque
Authorization code + PKCE (S256)	Le flux principal ; sûr même pour un client public
Refresh token rotatif	Avec détection de réutilisation — rejouer un ancien jeton invalide toute la chaîne
client_credentials	Intégration machine à machine
Access token	Opaque — son contenu n'est pas visible du RP
id_token	JWT signé en RS256
Discovery	/.well-known/openid-configuration
UserInfo	/userinfo

2. Proxy eID

Les applications n'accèdent jamais directement à eID Mongolia. Le SSO fait proxy des services eID autorisés et ne les transmet qu'aux applications enregistrées.

La raison : les identifiants eID ne vivent alors qu'en un seul endroit et la piste d'audit forme une chaîne unique. Distribuer des identifiants eID à chaque application rendrait impossibles la rotation, la révocation et le suivi de qui a fait quoi.

3. Le lieu unique d'enregistrement des applications

Les clients OAuth et leurs secrets ne sont créés qu'ici et n'y sont stockés que là. Même le Developer Portal ne crée pas de client : il explique la marche à suivre et renvoie par lien profond vers la console SSO.

Pourquoi un lieu unique ?

Si des identifiants vivent simultanément dans deux systèmes, ils finiront par diverger : un client supprimé d'un côté continue de fonctionner de l'autre, une rotation de secret n'atteint jamais l'autre côté, etc. Il n'existe pas d'alternative fiable à une source unique.

Méthodes de connexion

Méthode	Remarque
eID	La méthode principale — QR code / deep link mobile / push par numéro d'état civil
Google	Secondaire — la première liaison passe obligatoirement par une vérification eID, pour la rattacher à une personne réelle

Il n'y a pas de mot de passe. Ni de connexion par e-mail/OTP. C'est un choix délibéré : un mot de passe qui n'existe pas ne peut pas fuiter.

Services adjacents

Les passerelles associées, hébergées dans le même dépôt :

• DAN Gateway

  ---

  dan.gerege.mn — la passerelle d'identification DAN.

• G-Sign

  ---

  gsign.gerege.mn — la passerelle de signature.

• Gerege Verify

  ---

  xyp.gerege.mn — renseignements du registre des personnes morales.

Session et déconnexion

• Une session est une paire JWT access + refresh ; le refresh est rotatif.
• La déconnexion invalide à la fois le refresh et l'access (deny-list d'access).
• Après déconnexion, l'utilisateur revient sur le domaine d'où il est parti ; il n'est pas renvoyé vers /login. Cette règle préserve le parcours utilisateur du RP.

Un peu d'histoire architecturale — l'abandon de Hydra

Le SSO utilisait auparavant Ory Hydra comme fournisseur OIDC. Cette dépendance a été entièrement supprimée et les mécanismes nécessaires réécrits en code Go maison (usecases/oidc). La base de données Hydra distincte a été fusionnée avec la base principale.

Résultat :

• une dépendance externe de moins,
• deux bases et deux chaînes de migration ramenées à une,
• le comportement OIDC est désormais sous notre contrôle (en particulier, il peut être étroitement couplé au parcours eID).

Le même code que la plateforme

Le SSO n'est pas un système écrit séparément : il tourne exactement sur la même base de code que le modèle de plateforme. La seule différence tient à un réglage : avec AUTH_MODE=provider la carte de connexion s'affiche ici ; avec client elle redirige vers un SSO amont. La même image Docker démarre dans l'un ou l'autre rôle.

Plus : Code partagé · Authentification et autorisations.

S'intégrer (devenir RP)

Les grandes étapes :

1. Enregistrer l'application — créer un client dans la console SSO et récupérer client_id / client_secret. Enregistrer les redirect URI à l'identique.
2. Lire le discovery — récupérer les endpoints depuis /.well-known/openid-configuration.
3. Implémenter authorization code + PKCE.
4. Échanger le jeton — code → access + refresh + id_token.
5. Valider l'id_token — signature RS256, iss, aud, exp.
6. Récupérer les informations utilisateur — /userinfo.

Pour le parcours détaillé et une liste de contrôle, voir Authentification et autorisations.

Enregistrez les redirect URI à l'identique

L'erreur la plus fréquente en OIDC. Un redirect URI doit correspondre caractère par caractère — le / final, http contre https et le port comptent tous. Oubliez de mettre cette liste à jour lors d'un changement de domaine et l'authentification échouera silencieusement.

Documentation détaillée

La documentation au niveau de l'implémentation (schémas des endpoints, modèle de base de données, guide d'administration de l'enregistrement des RP) se trouve dans le dépôt sso-gerege-mn.