Gerege SSO¶

Production · Слой 2 — Аутентификация / SSO · Репозиторий: sso-gerege-mn · sso.gerege.mn

Провайдер OAuth2 / OpenID Connect линии частного сектора. Приложения экосистемы и сторонние relying party (RP) пропускают граждан именно здесь.

Gerege SSO на Nexus — это другое

В августе 2026 от Gerege Nexus был отведён новый репозиторий sso-gerege-nexus, который тоже называется «Gerege SSO». Поведение, описанное на этой странице, относится к коду sso-gerege-mn, работающему в production. У нового форка пока нет своего домена, поэтому контракт на sso.gerege.mn не изменился — RP ничего менять не нужно.

Три роли¶

1. Провайдер идентичности¶

RP могут предложить Sign in with Gerege. Что поддерживается:

Возможность	Пояснение
Authorization code + PKCE (S256)	Основной поток; безопасен даже для публичных клиентов
Ротируемый refresh token	С обнаружением повторного использования — старый токен обнуляет всю цепочку
`client_credentials`	Интеграция «машина — машина»
Access token	Непрозрачный — его содержимое не видно RP
`id_token`	JWT с подписью RS256
Discovery	`/.well-known/openid-configuration`
UserInfo	`/userinfo`

2. eID-прокси¶

Приложения никогда не обращаются к eID Mongolia напрямую. SSO проксирует разрешённые сервисы eID и передаёт их только зарегистрированным приложениям.

Причина: учётные данные eID тогда живут ровно в одном месте, а аудиторский след идёт единой цепочкой. Если раздать credential eID каждому приложению, ротация, отзыв и отслеживание «кто что сделал» станут невозможны.

3. Единственное место регистрации приложений¶

OAuth-клиенты и client secret создаются только здесь и хранятся только здесь. Даже Developer Portal не создаёт клиентов — он лишь объясняет, что делать, и даёт глубокую ссылку в консоль SSO.

Почему только одно место?

Если учётные данные живут сразу в двух системах, рано или поздно они разойдутся: удалённый на одной стороне клиент продолжает работать на другой, ротация секрета не доходит до второй стороны и так далее. Надёжной альтернативы единственному источнику нет.

Способы входа¶

Способ	Пояснение
eID	Основной — QR-код / мобильный deep-link / push по номеру реестра
Google	Дополнительный — при первой привязке обязательна проверка через eID, чтобы связать с реальным человеком

Паролей нет. Входа по email/OTP тоже нет. Это осознанное решение: пароль, которого не существует, не может утечь.

Смежные сервисы¶

Связанные шлюзы, работающие из того же репозитория:

DAN Gateway

dan.gerege.mn — шлюз идентификации DAN.
G-Sign

gsign.gerege.mn — шлюз подписи.
Gerege Verify

xyp.gerege.mn — справки из реестра юридических лиц.

Сессии и выход¶

Сессия — это пара JWT access + refresh; refresh ротируется.
Выход обнуляет и refresh, и access (access deny-list).
После выхода пользователь возвращается на тот домен, с которого начал, а не выбрасывается на /login. Это правило не рвёт пользовательский поток RP.

Кусочек истории архитектуры — уход от Hydra¶

Раньше SSO использовал Ory Hydra как провайдер OIDC. Сейчас эта зависимость полностью убрана, а нужные механизмы переписаны как собственный код Go (usecases/oidc). Отдельная база данных Hydra слита с основной.

Результат:

на одну внешнюю зависимость меньше,
две базы и две цепочки миграций стали одной,
поведение OIDC теперь под собственным контролем (в частности, его можно тесно связать с потоком eID).

Тот же код, что и у платформы¶

SSO — не отдельно написанная система: она работает на той же кодовой базе, что и шаблон платформы. Разница в одном параметре: при AUTH_MODE=provider карточка входа отображается здесь, при client — перенаправление в вышестоящий SSO. Один и тот же образ Docker загружается в любой роли.

Подробнее: Общий код · Аутентификация и права.

Интеграция (стать RP)¶

Общие шаги:

Зарегистрировать приложение — создать клиента в консоли SSO и получить client_id / client_secret. Redirect URI регистрируются точно.
Прочитать discovery — взять endpoint'ы из /.well-known/openid-configuration.
Реализовать authorization code + PKCE.
Обменять токен — code → access + refresh + id_token.
Проверить id_token — подпись RS256, iss, aud, exp.
Получить данные пользователя — /userinfo.

Подробный поток и чек-лист — на странице Аутентификация и права.

Регистрируйте redirect URI точно

Самая частая ошибка в OIDC. Redirect URI должен совпадать символ в символ — важны и завершающий /, и http против https, и порт. Забудете обновить этот список при смене домена — вход сломается молча.

Подробная документация¶

Документация уровня реализации (схемы endpoint'ов, модель базы данных, руководство администратора по регистрации RP) находится внутри репозитория sso-gerege-mn.