Танилт ба эрх¶

Экосистемийн бүх платформ нэг танилтын загвар ашиглана. Энэ хуудас нь тэр загварыг тайлбарлаж, шинээр нэгдэж буй relying party (RP)-д зориулсан практик зааврыг өгнө.

Загварын тойм¶

sequenceDiagram
    participant U as Хэрэглэгч
    participant RP as RP апп
    participant SSO as Gerege SSO
    participant EID as eID Mongolia
    participant P as Утас

    U->>RP: Нэвтрэх дарна
    RP->>SSO: Authorization request (code + PKCE)
    SSO->>EID: eID нэвтрэлт эхлүүлэх
    EID->>P: QR / deep-link / push
    P-->>EID: PIN1 зөвшөөрөл
    EID-->>SSO: Танигдсан иргэн
    SSO-->>RP: Authorization code
    RP->>SSO: code + code_verifier → токен
    SSO-->>RP: access + refresh + id_token
    RP->>SSO: /userinfo
    SSO-->>RP: Хэрэглэгчийн мэдээлэл

Гол зарчим: RP нь eID рүү шууд ханддаггүй. Бүх зүйл SSO-гоор дамжина.

Нэвтрэх аргууд¶

Арга	Төрөл	Тайлбар
eID	Үндсэн	QR код · мобайл deep-link · регистрийн дугаараар push
Google	Дагалдах	Эхний удаа заавал eID-ээр баталгаажина

Байхгүй зүйлс: нууц үг, и-мэйл/OTP нэвтрэлт, SMS OTP нэвтрэлт.

Энэ бол зориудын шийдвэр. Нууц үг байхгүй бол нууц үг алдагдахгүй, дахин ашиглагдахгүй, phishing-д өртөхгүй.

Платформ хаана нэвтрүүлэх вэ — `AUTH_MODE`¶

Экосистемд платформ хоёр өөр үүрэгтэй байж болно:

Танилтын үйлчилгээ — хэрэглэгчийг өөрөө нэвтрүүлнэ. Нүүр хуудас болон /login дээр нэвтрэх карт (eID QR/РД · Google) шууд гарна.
Relying party — нэвтрэлтээ дээд SSO-д даатгана. Нэвтрэх товч дарахад SSO руу шилжиж, тэндээ нэвтэрч, буцаж ирнэ.

Энэ хоёр нь кодын ялгаа биш, тохиргоо. Платформын backend дээрх AUTH_MODE тохиргоо шийднэ:

Утга	Нэвтрэх гадаргуу
`provider`	Нэвтрэх карт тухайн платформ дээрээ гарна
`client`	Дээд SSO (`SSO_ISSUER`) руу шилжүүлнэ

Тохируулаагүй бол SSO_CLIENT_ID бүртгэгдсэн эсэхээс автоматаар гарна.

Frontend нь горимоо нийтийн GET /api/v1/site/auth endpoint-оос уншина — нэвтрэлт шаардахгүй, нууц утга агуулахгүй:

{ "mode": "client", "sso_issuer": "https://sso.gerege.mn", "provider": false }

Issuer эсэх нь ТУСДАА асуулт

AUTH_MODE нь «энэ платформын хэрэглэгч хаана нэвтрэх вэ» гэдгийг заана. «Энэ платформ бусад аппыг нэвтрүүлэх issuer мөн үү» гэдгийг OAUTH_ISSUER тохиргоо тусад нь шийднэ. Хоёулаа зэрэг идэвхтэй байж болно — платформ өөрөө issuer байхын зэрэгцээ хэрэглэгчээ дээд IdP руу илгээх гинжин байдал.

Практик үр дүн: SSO үйлчилгээ ба түүний хэрэглэгч платформ хоёр нэг кодтой. Ижил Docker image орчны хувьсагчаас хамааран аль ч үүргээр боот хийнэ. Дэлгэрэнгүйг Дундын код хуудаснаас үзнэ үү.

PIN1 vs PIN2¶

	PIN1	PIN2
Гэрчилгээ	Authentication	Signing
Зориулалт	Нэвтрэх	Гарын үсэг зурах
Хууль зүйн үр дагавар	Байхгүй	Бий — non-repudiation

Нэвтрэх ≠ гарын үсэг

PIN1-ээр нэвтэрсэн нь хэрэглэгч ямар нэг зүйлийг зөвшөөрсөн гэсэн үг биш. Хууль зүйн үр дагавартай үйлдэлд (гэрээ, эрх олголт, санхүүгийн үүрэг) заавал PIN2-оор тусад нь гарын үсэг зурагдана.

OIDC техникийн үзүүлэлт¶

Зүйл	Утга
Урсгал	Authorization code + PKCE (S256)
Access token	Opaque
`id_token`	JWT, RS256
Refresh token	Rotating, reuse detection-той
Machine-to-machine	`client_credentials`
Discovery	`/.well-known/openid-configuration`
UserInfo	`/userinfo`

Refresh token rotation¶

Refresh token ашиглах бүрд шинэ refresh token гарна, хуучин нь хүчингүй болно. Хэрэв хуучин token дахин ашиглагдвал — энэ нь хулгайлагдсаны шинж тул тухайн бүх гинжийг хүчингүй болгоно.

Тиймээс RP нь refresh хийсний дараа шинэ token-ыг заавал хадгална. Хуучныг хадгалж үлдээвэл дараагийн refresh нь бүх session-ийг унагана.

Session ба logout¶

Session нь JWT access + refresh хосоор.
Logout нь refresh болон access хоёуланг хүчингүй болгоно (access deny-list).
Logout хийсэн хэрэглэгч эхлүүлсэн домэйн дээрээ буцаж очно.

RP болох алхмууд¶

1. Апп бүртгүүлэх¶

Gerege SSO консол дээр client үүсгэнэ. Авах зүйлс: client_id, client_secret.

Бүртгэхдээ бэлдэх зүйлс:

Redirect URI (бүх орчны — dev / staging / prod)
Post-logout redirect URI
Хүсэх scope-ууд
Апп-ын нэр, лого (хэрэглэгчийн consent дэлгэц дээр харагдана)

2. Discovery унших¶

GET https://sso.gerege.mn/.well-known/openid-configuration

Endpoint-үүдийг hardcode хийхгүй — эндээс уншина.

3. Authorization request¶

Authorization code + PKCE (S256) урсгалыг хэрэгжүүлнэ. state ба nonce-ыг заавал ашиглана.

4. Токен солилцох¶

Code + code_verifier → access_token, refresh_token, id_token.

5. `id_token` шалгах¶

Заавал шалгах зүйлс:

[ ] RS256 гарын үсэг — JWKS-ээс авсан түлхүүрээр
[ ] iss нь discovery дахь issuer-тэй таарч байна
[ ] aud нь таны client_id
[ ] exp хугацаа дуусаагүй
[ ] nonce нь таны илгээсэнтэй таарч байна

6. Хэрэглэгчийн мэдээлэл¶

/userinfo endpoint-оос авна.

Түгээмэл алдаанууд¶

Redirect URI яг таг таарах ёстой

Тэмдэгт тэмдэгтээрээ: төгсгөлийн /, http vs https, порт, дэд зам бүгд чухал. Хамгийн түгээмэл интеграцийн алдаа.

Домэйн өөрчлөх үеийн шалгах жагсаалт

Домэйн эсвэл брэнд өөрчлөхөд дараах гурвыг зэрэг шинэчилнэ. Аль нэгийг нь мартвал нэвтрэлт чимээгүйхэн унана:

[ ] SSO дээрх redirect URI жагсаалт
[ ] TLS гэрчилгээний SAN
[ ] RP-ийн тохиргоо дахь issuer / endpoint хаягууд

PKCE-г алгасаж болохгүй

Confidential client дээр ч PKCE-г хэрэглэнэ. Нэмэлт зардал бага, хамгаалалт бодит.

Эрхийн загвар¶

Танилтын дараа эрхийн шалгалт эхэлнэ. Экосистемийн стандарт шатлал:

superadmin (1) → admin (2) → manager (3) → user (4)

Дэлгэрэнгүйг Нийтлэг зарчим хуудаснаас үзнэ үү.

Байгууллагын түвшинд: гишүүнчлэл нь Postgres RLS-ээр хамгаалагдана — хэрэглэгч зөвхөн өөрийн харьяалагдах байгууллагын өгөгдлийг харна. Энэ нь апп-ын кодын шалгалт биш, өгөгдлийн сангийн түвшний хязгаарлалт.

manager эрх олгоход тухайн хүн PIN2-оор зөвшөөрөх шаардлагатай — дэлгэрэнгүйг Нийтлэг зарчим хуудаснаас.