SqlOS 3.28: Your App Is an OpenID Provider

SqlOS 3.28 makes every SqlOS host a full OpenID Connect Provider. Other applications — yours, a partner's, an off-the-shelf tool — can now offer "Sign in with your app" using nothing but a standard OIDC library and your discovery document. Third-party sign-ins get a consent screen. Access tokens carry the scope the user actually granted, and your APIs can require it.

Downstream apps can federate against you

/.well-known/openid-configuration and /userinfo are live on every host, and ID tokens are issued whenever the granted scope includes openid. Any OIDC client — Auth.js, ASP.NET Core's AddOpenIdConnect, an API gateway — connects from the discovery URL alone; no SqlOS SDK on the relying-party side.

ID tokens are RS256-signed with your existing rotating keys, addressed to the client, and cannot be mistaken for access tokens at a resource server. Profile claims like name and email are released from UserInfo per OIDC Core, which is where standard client libraries expect them.

Provider mode is on by default and can be switched off if you need the previous OAuth-only behavior. See OpenID Provider, and the new Sign in with X guide for an end-to-end walkthrough with a runnable two-app example.

Users approve third-party apps before they get access

When a client you didn't mark first-party requests authorization, the user now sees a consent screen: which app is asking, what it will be able to do, Allow or Deny. Approvals are remembered per user and app, so later sign-ins are silent; asking for more scopes re-prompts, and prompt=consent always prompts. Denying cancels the request cleanly. Your own first-party apps are untouched — no new step, no behavior change.

You control the wording: a scope display-name catalog turns raw scope strings into product language ("See your email address" instead of email), manageable in code, the Admin API, or the dashboard. Users' remembered grants are visible and revocable in the dashboard, and custom login UIs get the consent step as a headless view like every other step.

See Consent.

APIs can enforce the granted scope

User access tokens now carry the granted scope as a standard RFC 9068 scope claim — exactly the grant the token response reported. Inspect that claim on the validated token when an endpoint must bound a client's ceiling. Tokens issued before scope tracking have no claim and fail closed rather than being treated as all-powerful.

Scope remains the client's ceiling — what the user let the app do. Per-user, per-resource authorization stays with FGA, and effective permission is the intersection of the two. See Scopes and permissions and Token validation.

Verified against the OpenID Foundation suite

This release doesn't just claim OIDC compliance. The OpenID Foundation's own conformance suite — the harness behind official OP certification — now runs its Basic OP and Config OP plans against a live SqlOS deployment in CI on every change, alongside a real-browser end-to-end suite that exercises federation sign-up, consent, remembered grants, and sign-out. Companion post: Add "Sign in with X" to your product.

Upgrade notes

Upgrade the package normally:

dotnet add package SqlOS --version 3.28.0

Then run one new revision against a restored production database, wait for SqlOS initialization complete., and smoke-test a first-party sign-in — plus one third-party client if you have any.

What to expect after upgrading:

• Schema — SqlOS applies its own migrations at startup, as always. This release adds columns for nonce, authentication time, and granted scope on authorization codes and sessions, plus new tables for consent grants and scope display names.
• First-party apps — no behavior change if AllowedScopes is set and your app sends scope on /authorize.
• Third-party clients — their next authorization pauses on the consent screen until the user approves. Seed scope display names so that screen reads well.
• Compiled compatibility — SqlOSTokenResponse gains an optional trailing IdToken member: source-compatible, but recompile anything that binds against the package binary.
• New capabilities are opt-in — nothing requires you to inspect the scope claim or register downstream relying parties; existing deployments keep working as before.

This release passed the repository's complete gate: build, documentation, unit, integration, and example-application tests, coverage thresholds, the OpenID Foundation Basic OP and Config OP plans, and the real-browser federation suite.