Custom authorization servers, scopes and consent

Beyond the default OIDC provider covered in Single sign-on with OIDC, you can now define your own custom authorization servers — separate token-issuing endpoints with their own scopes, claims, signing keys and access policies, for APIs you want to protect with Qorionix-issued tokens rather than a sign-in flow. This article covers what's built. Read the scope-of-this-wave section before you plan a production integration around it.

Creating a server

Admin CRUD is organisation-scoped, under /organizations/{orgID}/auth-servers[/...], gated on iam:auth_servers.{read,write,delete}: servers, scopes, claims, access policies, and a POST .../keys/rotate action. Each server gets its own RSA-2048 signing key with current/previous rotation — the same rollover shape the SAML identity provider's own certificate already uses.

Clients aren't duplicated for a custom server: an access policy's client allowlist names existing client_id values from your ordinary OIDC clients (see Registering an application for sign-in) rather than creating a second, parallel set of client records.

Why the runtime endpoint has no organisation in its path

What a server actually issues today

When a client_credentials request comes in, the server matches it against your access policies in priority order: each policy can restrict which clients it applies to (an allowlist) and narrow which scopes are granted, even if the client asked for more. The first matching policy decides. Claims in the issued token are rendered through the same expression engine every profile/app mapping uses (the mapping scope from the expression language article) — read-only for this purpose, no new engine capability was added for it.

Consent: the data model and self-service revoke are real; the screen is not

There's a real consent-grant data model, and a real self-service surface for a person to see and revoke what they've granted: GET /iam/consents lists your own grants, DELETE /iam/consents/{id} revokes one.

What to do with this today

• Use a custom authorization server for machine-to-machine (client_credentials) access to your own APIs, scoped down with access policies.
• Don't build a browser sign-in flow against a custom server's token endpoint — it doesn't support that grant yet.
• If you need to show your users what third-party access they've granted, point them at GET /iam/consents; there's no console screen for it yet, only the API.