Skip to content

API Gateway

An admin-managed service catalogue plus request telemetry. Every internal or external service on the platform is registered, granted to apps as an OAuth scope, and its call statistics collected.

UI: /admin/gateway/overview, /admin/gateway/services, /admin/gateway/logs. Permission: gateway.manage.

Service catalogue

Endpoint What
GET /v1/gateway/services List services
POST /v1/gateway/services Create
PUT /v1/gateway/services/{id} Edit / enable · disable
DELETE /v1/gateway/services/{id} Delete

Each service has:

Field Example Note
name eid-proxy Identifier
protocol · host · port · path https · sso.gerege.mn · 443 · /rp/eid Upstream
tags ['eid','sign'] Classification
scope svc:eid-proxy The OAuth scope — the unit of granting
enabled true Disabling makes the route return 503

The scope is the unit of granting

Granting a service to an app means adding svc:<name> to that app's OAuth client's allowed scopes. The grant therefore materialises on the token, and revocation takes effect immediately.

Telemetry

Endpoint What
GET /v1/gateway/overview Request counts, error rate, latency
GET /v1/gateway/logs Request log (gateway_request_logs)

The gateway middleware (middleware_gateway_log.go) records each proxied call: service, status, duration, calling app. No personal data is logged.

Application (RP) registry

The applications module is the unified registry of OAuth2 clients, covering both RPs and machine-to-machine clients. It replaced the older gateway consumer / API-key model.

Endpoint What
GET/POST /v1/applications List / create
GET/PUT/DELETE /v1/applications/{id} Read / edit / delete
POST /v1/applications/{id}/rotate-secret Rotate the secret
PUT /v1/applications/{id}/secret Set the secret
PUT /v1/applications/{id}/services Grant services (updates the scopes)

UI: Admin → Applications.

applications ──┐
               ├── application_services ──► gateway_services.scope
oauth_clients ─┘                              (svc:eid-proxy …)

Access-check order

When an app calls a gateway-protected service:

graph TD
  A["Request + bearer token"] --> B{"Introspect: active?"}
  B -->|no| E401["401"]
  B -->|yes| C{"client granted svc:*?"}
  C -->|no| E403["403"]
  C -->|yes| D{"service enabled?"}
  D -->|no| E503["503"]
  D -->|yes| OK["200 — forwarded upstream"]

Seed data

When empty, these services are installed:

Service Upstream Scope
dan-sso https://sso.gerege.mn/oauth2 svc:dan-sso
eid-sign https://sso.gerege.mn/rp/sign svc:eid-sign

Sample RPs (template-dgov-mn, developer-dgov-mn) are registered and granted the eid-sign service.

SQL does not fully create the OAuth client

The seed only inserts the applications rows. To finish enabling OAuth, rotate (or recreate) the secret from the admin UI.

Why no RLS?

Gateway tables are configuration and telemetry, not per-citizen data. Protection is at the HTTP layer: every endpoint requires gateway.manage.