OIDC provider¶

Платформ өөрөө OpenID Connect issuer болж чадна: relying party (RP) апп-ууд түүгээр дамжин нэвтэрнэ. Хэрэгжилт нь өөрийн Go код (core/business/usecases/oidc) — гуравдагч identity server ашигладаггүй.

Хэзээ асдаг вэ?

OAUTH_ISSUER тохируулагдсан үед л provider гадаргуу mount хийгдэнэ. Тохируулаагүй бол платформ нь зөвхөн client (Gerege SSO-ийн RP) хэвээр ажиллана — Апп холбох-ыг үз.

Endpoint-ууд¶

Эдгээр нь /api/v1 бүлгээс гадуур, үндэс дээр сууна — учир нь тэдгээрийн зам нь OIDC стандартаар тогтоогддог.

Зам	Метод	Юу
`/.well-known/openid-configuration`	GET	Discovery баримт
`/.well-known/jwks.json`	GET	RS256 нийтийн түлхүүр
`/oauth2/auth`	GET	Authorization (зөвхөн `code` flow)
`/oauth2/token`	POST	Токен солилцоо
`/oauth2/introspect`	POST	RFC 7662
`/oauth2/revoke`	POST	RFC 7009
`/oauth2/sessions/logout`	GET	RP-initiated logout
`/userinfo`	GET · POST	Хэрэглэгчийн claim

Бүгд нээлттэй (нэвтрэлт шаардахгүй) — client-ийн баталгаажуулалт endpoint бүрийн дотор, протоколын дагуу хийгдэнэ.

Дэмжигдэх боломжууд¶

Талбар	Утга	Тэмдэглэл
`response_types_supported`	`code`	Зөвхөн authorization code flow
`response_modes_supported`	`query`
`grant_types_supported`	`authorization_code` · `refresh_token` · `client_credentials`
`code_challenge_methods_supported`	`S256` зөвхөн	`plain` нь PKCE-ийн утгыг алдагдуулна (RFC 9700 §2.1.1)
`id_token_signing_alg_values_supported`	`RS256`
`subject_types_supported`	`public`	Pairwise хэрэгжүүлээгүй
`token_endpoint_auth_methods_supported`	`client_secret_basic` · `client_secret_post` · `none`	`none` = public client (PKCE)
`scopes_supported`	`openid` · `offline_access` · `profile` · `email` · `nationalid`	Статик жагсаалт

Scope-ийн жагсаалт яагаад статик вэ?

Бүртгэгдсэн client-уудын scope-ийн нэгдлийг зарлавал дотоод gateway service-ийн нэрс (svc:*) нийтэд ил болно. Тиймээс discovery нь зөвхөн стандарт scope-уудыг зарлана.

Дэмжихгүй (зориудаар): request / request_uri (JAR) — хэрэглэгддэггүй бөгөөд SSRF-ийн гадаргуу нэмнэ.

Claim-ууд¶

sub · iss · aud · exp · iat · auth_time · nonce
name · given_name · family_name · given_name_en · family_name_en
email · email_verified · national_id · register_number
google_sub · google_email · google_name · google_picture

sub нь платформын тогтвортой, opaque per-citizen танигч (user UUID) — регистрийн дугаар биш. national_id / register_number нь nationalid scope олгогдсон үед л орно.

Provider нь өөрийн UI-аар login ба consent-ыг жолоодно. Урд талыг Next.js хуудсууд (/oauth/login, /oauth/consent, /oauth/logout) хэрэгжүүлж, provider usecase-ийн challenge API-г дуудна.

sequenceDiagram
  participant RP as RP апп
  participant P as Gerege App (issuer)
  participant U as Иргэн
  RP->>P: GET /oauth2/auth?client_id&redirect_uri&code_challenge
  P-->>U: /oauth/login (login_challenge)
  U->>P: eID-ээр нэвтрэх
  P->>P: POST /v1/provider/login/accept
  P-->>U: /oauth/consent (consent_challenge)
  U->>P: Зөвшөөрөх
  P->>P: POST /v1/provider/consent/accept
  P-->>RP: redirect_uri?code&state
  RP->>P: POST /oauth2/token (code + code_verifier)
  P-->>RP: access_token · id_token · refresh_token

Endpoint	Юу
`GET /v1/provider/login`	Login challenge-ийн мэдээлэл
`POST /v1/provider/login/accept` · `/reject`	Шийдвэр
`GET /v1/provider/consent`	Consent challenge — ямар scope хүсэж байгаа
`POST /v1/provider/consent/accept` · `/reject`	Шийдвэр
`POST /v1/provider/logout/accept`	Logout баталгаажуулалт

First-party client: SSO_FIRSTPARTY_CLIENTS-д жагсаагдсан client-ууд consent дэлгэцийг алгасна (өөрийн апп-ууд).

Урсгалын түр төлөв нь oauth_challenges хүснэгтэд, SSO_STATE_KEY-ээр HMAC хийгдэнэ (≥32 байт).

Client бүртгэл¶

Хоёр гадаргуу — хоёулаа нэг oauth_clients хадгалалтыг ашиглана:

Admin UI / APIОператор admin API

Endpoint	Эрх	Юу
`GET/POST /v1/applications`	`gateway.manage`	Жагсаах / үүсгэх
`GET/PUT/DELETE /v1/applications/{id}`	`gateway.manage`	Уншиx / засах / устгах
`POST /v1/applications/{id}/rotate-secret`	`gateway.manage`	Secret эргүүлэх
`PUT /v1/applications/{id}/secret`	`gateway.manage`	Secret тавих
`PUT /v1/applications/{id}/services`	`gateway.manage`	Gateway service олгох

UI: Admin → Applications.

/admin/api/v1/... дор, admin API key-ээр (Stripe/Auth0 маягийн management API загвар). Authorization: Bearer gsk_… эсвэл X-API-Key.

curl -H 'Authorization: Bearer gsk_…' \
  https://<issuer>/admin/api/v1/clients

Энэ гадаргуу нийтэд нээлттэй БАЙХ ЁСГҮЙ

Production дээр edge nginx нь /admin-ыг web BFF рүү өгдөг; admin API-д зөвхөн хостын loopback-аас хандана.

Дэмжигдэхгүй талбарууд (Hydra-д байсан ч энэ бүртгэлд багана байхгүй): backchannel/frontchannel logout URI, DPoP, jwks/jwks_uri, audience, sector_identifier_uri, pairwise subject_type. Хүсэлтэд ирвэл чимээгүй хаяхын оронд 400 буцаана — оператор «тохируулсан» гэж эндүүрэхээс сэргийлнэ.

Түлхүүрийн удирдлага¶

KeyManager нь RS256 түлхүүрийг үүсгэж, JWKS-ээр нийтэлнэ. Түлхүүр эргүүлэхэд хуучин нийтийн түлхүүр JWKS дээр хэсэг хугацаанд үлдэж, урсгал дахь id_token-ууд шалгагдсаар байна.

Токен хадгалалт¶

Хүснэгт	Юу
`oauth_auth_codes`	Нэг удаагийн authorization code (PKCE challenge-тэй)
`oauth_access_tokens`	Олгогдсон токен (introspect / revoke-д)
`oauth_consents`	Хэрэглэгчийн өгсөн зөвшөөрөл
`oauth_challenges`	Login / consent урсгалын түр төлөв

Бүгд RLS-ээр хамгаалагдсан — service ба admin policy-ээс гадна oauth_consents дээр self policy байна.