sat/openapi.yaml: SSO tag advertises OIDC support, but no OIDC endpoints are documented anywhere

[dmchaledev]

Problem

sat/openapi.yaml's top-level tags block describes the SSO tag as:

- name: SSO
  description: SAML 2.0 and OIDC single sign-on (browser-facing, no API key required)

(sat/openapi.yaml:1917-1918)

But the only operations tagged SSO in the whole spec are the three SAML endpoints:

• GET /sso/saml/metadata (getSAMLMetadata)
• GET /sso/saml/login (initiateSAMLLogin)
• POST /sso/saml/acs (samlAssertionConsumer)

There is no /sso/oidc/... path, no OIDC discovery/callback endpoint, and no OIDC-related schema anywhere in the file. A repo-wide case-insensitive search for oidc/openid turns up exactly one hit — the tag description itself:

$ grep -rni "oidc\|openid" . --include="*.yaml" --include="*.md" --include="*.html"
./sat/openapi.yaml:1918:    description: SAML 2.0 and OIDC single sign-on (browser-facing, no API key required)

Why this matters

• Anyone reading the Redoc sidebar (grouped by tag) or generating an SDK/MCP tool list from this spec sees "OIDC" advertised as a supported SSO method for the SAT API, then finds zero corresponding endpoints to call — there's nothing to configure an OIDC-based IdP integration against.
• This is either (a) a real product gap — OIDC SSO doesn't actually exist yet and the description is aspirational/stale, or (b) OIDC endpoints exist in the real API (mirroring the /sso/saml/metadata, /sso/saml/login, /sso/saml/acs trio, likely something like /sso/oidc/login, /sso/oidc/callback, plus discovery/client config) but were simply never added to this spec. Either way, the spec and the tag description currently disagree with each other, and only someone with visibility into the actual SAT service can say which.

Proposed fix

Needs confirmation from whoever owns the SAT service before the exact shape can be filled in:

1. If OIDC SSO exists in the real API: add the missing path(s) (e.g. /sso/oidc/login, /sso/oidc/callback, and any client/provider config endpoint), following the same pattern already established for the SAML trio — security: [] (unauthenticated, browser-facing), a 404 for "not configured", and appropriate 400/403 responses for a failed/malformed callback.
2. If OIDC SSO doesn't exist yet: drop "and OIDC" from the SSO tag description (sat/openapi.yaml:1918) so the docs don't advertise a method that isn't implemented.

Scope

sat/openapi.yaml only (the tags block and, if applicable, new paths/schemas under a ## SSO area near the existing SAML operations around line 1565).