Skip to content
Sudomimus

OIDC flow

View as Markdown

If you have an existing application that already speaks OpenID Connect, or you want to use an off-the-shelf OIDC library, you can integrate with Sudomimus as a standard OIDC relying party (RP). The Sudomimus OIDC provider lives at oidc.sudomimus.com and supports the authorization code flow with PKCE, the canonical modern OIDC integration shape.

Use this guide when:

  • Your framework or platform has a first-class OIDC integration (Next-Auth, Spring Security, Keycloak adapter, etc.) and you want to slot Sudomimus in as the IdP.
  • You’re integrating with a partner system that already expects an OIDC provider.
  • You prefer the OIDC mental model (clients, scopes, ID tokens) to the Connect protocol.

If you’re starting fresh and just want the smallest custom integration, the Connect protocol is usually shorter.

The official SDKs are most useful for Connect, Session, Device, Native, and token verification helpers. See the SDK selection guide if your OIDC application also verifies Sudomimus application access tokens or uses Session introspection and logout. OIDC refresh tokens must use the issuer’s /token endpoint.

OpenID certification

Section titled “OpenID certification”

The OpenID Foundation’s certified provider profiles list Sudomimus for the profiles below. Each profile tests a specific part of the provider’s behavior. Use the deployed discovery document below to check which capabilities the issuer currently advertises.

Profile What it covers
Basic OP Sign-in with the Authorization Code Flow.
Config OP Provider endpoints and capabilities published through discovery.
Implicit OP Front-channel ID Token delivery, with an optional access token.
Hybrid OP Authorization codes combined with front-channel tokens.
Dynamic OP Dynamic Client Registration and related configuration.
Form Post OP Authorization responses delivered by HTTP form POST. The tests cover Basic, Implicit, and Hybrid flows.
3rd Party-Init OP Sign-in initiated by the provider through the RP’s registered login initiation endpoint.

Discovery

Section titled “Discovery”

Sudomimus publishes a standard OIDC discovery document. Point your library at the issuer URL https://oidc.sudomimus.com and it will fetch the rest from there:

Terminal window
curl https://oidc.sudomimus.com/.well-known/openid-configuration

Sudomimus does not publish a separate OIDC OpenAPI schema. Use discovery for the deployed endpoint URLs and advertised capabilities, the OpenID Connect and OAuth standards for protocol semantics, and this guide for the supported Sudomimus profile and its platform-specific constraints. The generated OpenAPI reference covers the Connect, Session, Native, and Device product APIs instead.

The document advertises:

  • response_types_supported: ["code", "id_token", "id_token token", "code id_token", "code token", "code id_token token"].
  • response_modes_supported: ["query", "fragment", "form_post"]. Code defaults to query; request the other modes explicitly and check deployed discovery before use.
  • userinfo_signing_alg_values_supported: ["RS256"]; enabled per client registration.
  • authorization_response_iss_parameter_supported: true — authorization callbacks identify the provider according to RFC 9207.
  • grant_types_supported: ["authorization_code", "implicit", "refresh_token"].
  • scopes_supported: ["openid", "email", "profile", "offline_access"].
  • claims_supported includes sub, email, email_verified, name, given_name, family_name, picture, and picture_animated.
  • claim_state_endpoint identifies Sudomimus’s provider-specific endpoint for live claim policy and consent metadata.
  • id_token_signing_alg_values_supported: ["RS256"].
  • code_challenge_methods_supported: ["S256"] — for code-bearing flows, PKCE is required for public clients and recommended for confidential clients; plain is not supported.
  • token_endpoint_auth_methods_supported: ["private_key_jwt", "client_secret_basic", "client_secret_post", "none"].
  • ui_locales_supported: ["en-US", "zh-CN"].

Register your application

Section titled “Register your application”

In with.sudomimus.com, on the application you want to expose via OIDC:

  1. Add a Layer 3 OIDC return rule:

    {
      "returnMethod": "OIDC",
      "payload": {
        "redirectUris": ["https://app.example.com/oidc/callback"],
        "postLogoutRedirectUris": ["https://app.example.com/"],
        "allowedResponseTypes": ["code"],
        "allowedGrantTypes": ["authorization_code", "refresh_token"],
        "applicationType": "web",
        "allowedScopes": ["openid", "email", "profile", "offline_access"],
        "tokenEndpointAuthMethod": "private_key_jwt"
      }
    }

  2. Add the Layer 1 and Layer 2 rules you would for any other application — at least one authentication method (e.g. PASSKEY_USERNAMELESS or PASSKEY_REASONED) and at least one realize rule (e.g. EMAIL with the addresses or domain pattern you accept). The OIDC flow runs through the same authentication challenge as the rest of the platform.

  3. Choose a client authentication method:

    • private_key_jwt (recommended for confidential clients) — your RP holds a private key and signs a JWT assertion at /token. Select either the platform-provisioned client-auth key or registered RP public keys (inline JWKS or an HTTPS JWKS URI) on the application’s OIDC page. Sign with the corresponding private key. Verification uses only the selected key source.
    • client_secret_basic (confidential clients) — your RP presents its shared secret in the HTTP Authorization: Basic header at /token.
    • client_secret_post (confidential clients) — your RP sends its shared secret in the /token form body (client_id + client_secret parameters).
    • none — only for public clients (SPAs, mobile apps without a backend). PKCE S256 is required for code-bearing flows.

client_secret_basic and client_secret_post use the same application secret. Generate or rotate it from the application’s page in the With portal, then store it securely.

The application’s applicationAnchor is your client_id.

Before starting login, configure the rules and credentials for your chosen flow, then have an organization OWNER take the application live. New applications remain DRAFT until explicitly activated; login requires ACTIVE and available parent organization and sector.

The OIDC flow

Section titled “The OIDC flow”
sequenceDiagram
    autonumber

    participant RP as Relying party
    participant Browser as User browser
    participant OIDC as OIDC provider
    participant Via as via.sudomimus.com

    RP-->>Browser: Redirect to /authorize<br/>state + nonce + PKCE challenge
    Browser->>OIDC: GET /authorize
    OIDC-->>Browser: Continue to hosted authentication
    Browser->>Via: Authenticate and review consent
    Via-->>Browser: Return to the registered redirect URI<br/>code + state + iss
    Browser-->>RP: Authorization callback
    RP->>OIDC: POST /token<br/>code + PKCE verifier + client authentication
    OIDC-->>RP: ID token + access token<br/>optional refresh token
    RP->>OIDC: GET or POST /userinfo<br/>Bearer access token
    OIDC-->>RP: Scope- and consent-gated claims

1. Authorization request

Section titled “1. Authorization request”

Redirect the user’s browser to /authorize with the standard OIDC parameters:

https://oidc.sudomimus.com/authorize
  ?client_id=my-app
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Foidc%2Fcallback
  &response_type=code
  &scope=openid%20email%20profile
  &ui_locales=zh-CN%20en-US
  &state=<csrf-token>
  &nonce=<random-nonce>
  &code_challenge=<S256-of-verifier>
  &code_challenge_method=S256

Required: client_id, redirect_uri, response_type=code, scope (must include openid). Public clients also require code_challenge and code_challenge_method=S256. Confidential clients may omit both PKCE parameters, but must still authenticate at /token. Empty, incomplete, or unsupported PKCE parameters are rejected. Optional but recommended: state, nonce.

The examples below use the recommended PKCE flow. Without PKCE, confidential OIDC clients must retain transaction-bound CSRF and code-injection protection, including the nonce-based checks and precautions described in RFC 9700. Client authentication alone does not provide those protections.

Use the optional ui_locales parameter when your application knows the user’s preferred interface languages. List BCP 47 tags in preference order, separated by spaces. Sudomimus uses the first supported value (en-US or zh-CN); unsupported values are ignored and never block sign-in. The hint applies only to this sign-in, and the user can still switch languages from the page.

Generate a valid PKCE pair

Section titled “Generate a valid PKCE pair”

Let your OIDC library generate PKCE values whenever possible. Create a fresh pair for every authorization attempt and keep the verifier with the pending login state until the callback arrives.

If you generate the values yourself:

  • code_verifier must be 43–128 characters using only letters, digits, -, ., _, and ~.
  • code_challenge must be the unpadded base64url encoding of the verifier’s SHA-256 digest. An S256 challenge is exactly 43 characters and uses only letters, digits, -, and _.
  • Send only code_challenge to /authorize. Send the original, unchanged code_verifier when exchanging the code at /token.

Do not reuse a verifier or copy a fixed example into production. Sudomimus rejects malformed values as well as verifier/challenge mismatches.

Once a challenge is sent, a matching verifier is mandatory even for confidential clients. If the authorization omitted PKCE, omit code_verifier at /token too: supplying one in that case is rejected to prevent downgrade attacks.

Choose the interaction behavior

Section titled “Choose the interaction behavior”

Most applications can omit prompt and max_age. Sudomimus may reuse a remembered login for the same application after checking current account, credential, application, rule, and consent authority. Reuse preserves the original proof time in auth_time; it does not make an older authentication fresh.

Parameter Behavior
Omitted prompt Reuse an eligible remembered login, or continue with interactive sign-in when needed.
prompt=login Require fresh authentication.
prompt=select_account Require fresh authentication so the user can choose an account.
prompt=consent Show consent again, even when standing claim-sharing choices are already settled.
prompt=none Attempt reuse without displaying the sign-in UI; return an interaction error if the request cannot complete silently.
max_age=0 Require fresh authentication.
Positive max_age Permit reuse only when the original authentication is no older than this number of seconds and all current checks pass.

max_age must be a non-negative decimal integer. prompt may combine login, select_account, and consent with spaces; none must appear alone.

For prompt=none, handle login_required when no eligible remembered authentication is available, consent_required when consent is needed, and interaction_required when required account data needs browser interaction. Start an interactive authorization request when the user is ready to complete that work. A valid id_token_hint alone does not establish a reusable login.

Request offline_access only when your application needs to refresh tokens after the user leaves or closes it. Sudomimus shows a separate, default-unchecked offline-session choice. If the user declines, sign-in still succeeds, but the returned scope omits offline_access and no refresh token is issued. Always use the returned scope and the presence of refresh_token as the result of that choice.

Sudomimus redirects the user to via.sudomimus.com where they authenticate via the methods allowed by your Layer 1 rules. After a successful authentication and realize, the browser returns to your redirect_uri with a code, the original state, and iss=https://oidc.sudomimus.com.

Authorization errors that occur after Sudomimus validates your registered callback return to that callback with error, error_description, the original state, and the same iss. Your OIDC library must compare iss exactly with the issuer saved for this login and reject a missing or different value before exchanging the code. Errors before callback validation are returned directly as JSON. Treat server_error as a temporary provider failure and let the user retry; do not cache protocol error responses.

2. Token exchange

Section titled “2. Token exchange”

Authorization codes are single-use and valid for 60 seconds. Reusing a redeemed code with valid client authentication, redirect URI and PKCE is rejected and revokes only the session issued from that code, including its refresh tokens. If an exchange response is lost, start a new authorization flow instead of retrying the code. Other sign-in sessions are not revoked.

POST the authorization code to /token. The body is application/x-www-form-urlencoded, per OIDC:

Terminal window
curl -X POST https://oidc.sudomimus.com/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=authorization_code" \
  --data-urlencode "code=$AUTH_CODE" \
  --data-urlencode "redirect_uri=https://app.example.com/oidc/callback" \
  --data-urlencode "code_verifier=$PKCE_VERIFIER" \
  --data-urlencode "client_id=my-app" \
  --data-urlencode "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" \
  --data-urlencode "client_assertion=$CLIENT_ASSERTION_JWT"

The client_assertion is a JWT you sign with the private key corresponding to the client’s selected public-key source. Required claims: iss = client_id, sub = client_id, aud = the exact token endpoint URL (https://oidc.sudomimus.com/token in production), fresh jti, iat, exp (within 300s of iat). RS256.

Successful response (JSON):

{
  "access_token": "<JWT>",
  "token_type": "Bearer",
  "expires_in": 10800,
  "id_token": "<JWT>",
  "scope": "openid email profile"
}
  • id_token — signed by Sudomimus’s platform-wide OIDC key; verify against https://oidc.sudomimus.com/.well-known/jwks.json. It carries minimal protocol claims (iss, sub, aud, exp, iat, at_hash, optional nonce and auth_time) plus authentication context (amr, acr). Profile claims come from /userinfo.
  • access_token — signed by the application’s token-signing key, with the same minimal registered and session claims as a Sudomimus application access token. It carries no profile fields.
  • refresh_token — included only if you requested offline_access and the user approved the offline session.

3. Userinfo

Section titled “3. Userinfo”

JSON is the default. Set the OIDC ReturnRule’s userinfoSignedResponseAlg to "RS256" to receive application/jwt. Verify its platform JWKS signature, issuer, client_id audience, subject, and expiry. Signed responses contain the same authorized profile data, no nonce or token hashes, and expire no later than the presented access token or session. Keep retiring platform keys published until both ID Tokens and signed UserInfo have expired.

Terminal window
curl https://oidc.sudomimus.com/userinfo \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Returns the claims permitted by the granted scopes:

{
  "sub": "<sector subject>",
  "email": "<only if 'email' scope was granted>",
  "email_verified": true,
  "name": "<only if 'profile' scope was granted>",
  "given_name": "<only if 'profile' scope was granted>",
  "family_name": "<only if 'profile' scope was granted>",
  "picture": "<only if 'profile' scope was granted>",
  "picture_animated": "<only if 'profile' scope was granted>"
}

sub is the sector subject — the per-sector, application-visible identifier and the same value as the id_token sub. Use it as the user’s key. /userinfo accepts both GET and POST.

Prefer the Authorization: Bearer header for either method. POST also accepts one access_token in an application/x-www-form-urlencoded body. Do not combine the header and form token or repeat the form parameter; these requests return 400 invalid_request, as do empty form tokens and query-string tokens. JSON and GET bodies cannot supply the token. Both supported transports enforce the same token expiration, live session, and claim-sharing rules.

The picture and private picture_animated values follow the sector-scoped avatar delivery contract; see Avatar claims and delivery.

Claim state

Section titled “Claim state”

When your application needs current policy and consent metadata, call the discovered claim_state_endpoint with the same Bearer access token. Both GET and POST are supported. The response never contains profile values:

{
  "sub": "<sector subject>",
  "claims": {
    "email": { "requirement": "OPTIONAL", "state": "GRANTED" },
    "given_name": { "requirement": "OPTIONAL", "state": "GRANTED" },
    "family_name": { "requirement": "OFF", "state": "UNKNOWN" },
    "picture": { "requirement": "OFF", "state": "UNKNOWN" },
    "picture_animated": { "requirement": "OFF", "state": "UNKNOWN" }
  }
}

Only email-scope and profile-scope entries are returned. An openid-only session receives an empty claims object.

Authentication context

Section titled “Authentication context”

Every id_token includes:

Claim Meaning
amr Standard Authentication Methods References values, such as ["hwk", "user"] for passkey or ["otp"] for email OTP.
acr Sudomimus-specific authentication context string, such as urn:sudomimus:acr:passkey or urn:sudomimus:acr:email-otp.

If your RP needs phishing-resistant sign-in for a sensitive action, check acr for urn:sudomimus:acr:passkey. Federated upstreams such as Google, GitHub, Discord, Battle.net, X, Steam, and enterprise federation map to amr: ["pwd"]; use acr when you need to distinguish the upstream provider.

4. Refresh

Section titled “4. Refresh”

If you requested offline_access, the user approved it, and you received a refresh token, exchange it at /token:

Terminal window
curl -X POST https://oidc.sudomimus.com/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=refresh_token" \
  --data-urlencode "refresh_token=$REFRESH_TOKEN" \
  --data-urlencode "client_id=my-app"
  # plus client_assertion for confidential clients

Use the same client authentication method as the authorization-code exchange. For client_secret_basic, use -u "my-app:$CLIENT_SECRET" and omit the body client_id. For client_secret_post, include both body client_id and client_secret.

You can pass scope to narrow the session’s current granted scopes. Narrowing is permanent for that session; a later refresh cannot restore removed scopes. Removing offline_access stops refresh-token issuance. Removing openid stops ID Token issuance. Concurrent refreshes with incompatible scope sets are rejected. A refreshed ID Token does not include nonce.

Store the returned refresh_token in place of the previous token when present. Serialize refresh requests. A short rotation grace window can reconcile a near-simultaneous retry only when its effective scopes match the completed rotation. Reuse outside that window can revoke the session.

5. End session

Section titled “5. End session”
https://oidc.sudomimus.com/end-session
  ?id_token_hint=<id_token>
  &client_id=my-app
  &post_logout_redirect_uri=https%3A%2F%2Fapp.example.com%2F
  &state=<optional>

/end-session signals the end of an OIDC session and redirects to the post_logout_redirect_uri (which must match one of the registered URIs exactly). When id_token_hint verifies and its aud matches this client, Sudomimus advances account/application session authority and revokes older ApplicationSessions for that account within this application.

A bad, forged, or stale hint does not block logout redirection; it simply means no application sessions are revoked. The hint may be expired, which lets an RP still drive logout after its local session has timed out.

Use Session API /logout when you hold a specific refresh token and want to revoke only that one session. Use Session API /revoke-all from a backend when you need application-wide account revocation without relying on an id_token_hint. See Managing sessions.

Using an OIDC library

Section titled “Using an OIDC library”

Most modern OIDC libraries (Node’s openid-client, Python’s authlib, Java’s nimbus-jose-jwt, etc.) discover everything from the issuer URL and handle PKCE, JWKS, and token verification automatically. This Node example supports openid-client 6.x (tested with 6.8.6) and uses a public, PKCE-only client registered with token_endpoint_auth_method: "none":

import * as oidc from "openid-client";


const redirectUri = "https://app.example.com/oidc/callback";
const configuration = await oidc.discovery(
    new URL("https://oidc.sudomimus.com"),
    "my-app",
    {
        redirect_uris: [redirectUri],
        response_types: ["code"],
        token_endpoint_auth_method: "none",
    },
    oidc.None(),
    {
        execute: [oidc.enableNonRepudiationChecks],
    },
);


export const startSignIn = async (savePendingSignIn) => {


    const codeVerifier = oidc.randomPKCECodeVerifier();
    const codeChallenge = await oidc.calculatePKCECodeChallenge(codeVerifier);
    const state = oidc.randomState();
    const nonce = oidc.randomNonce();


    await savePendingSignIn({
        codeVerifier,
        state,
        nonce,
    });


    return oidc.buildAuthorizationUrl(configuration, {
        redirect_uri: redirectUri,
        scope: "openid email profile",
        code_challenge: codeChallenge,
        code_challenge_method: "S256",
        state,
        nonce,
    });
};


export const finishSignIn = async (
    callbackUrl,
    consumePendingSignIn,
    createServerSideApplicationSession,
) => {


    const pendingSignIn = await consumePendingSignIn();
    if (pendingSignIn === undefined) {
        throw new Error("OIDC sign-in state is missing or expired");
    }


    const tokens = await oidc.authorizationCodeGrant(
        configuration,
        callbackUrl,
        {
            pkceCodeVerifier: pendingSignIn.codeVerifier,
            expectedState: pendingSignIn.state,
            expectedNonce: pendingSignIn.nonce,
        },
    );
    const claims = tokens.claims();
    if (claims?.sub === undefined) {
        throw new Error("The validated ID token did not contain sub");
    }


    const userinfo = await oidc.fetchUserInfo(
        configuration,
        tokens.access_token,
        claims.sub,
    );


    await createServerSideApplicationSession({
        userKey: claims.sub,
        refreshToken: tokens.refresh_token,
    });


    return userinfo;
};

savePendingSignIn and consumePendingSignIn represent short-lived, server-side storage tied to the browser’s login attempt. Consume the verifier, state, and nonce once at callback time. authorizationCodeGrant validates the authorization response, including the RFC 9207 issuer from discovery and the expected state, as well as the ID-token nonce. The configured non-repudiation check additionally validates the ID-token signature through the discovered JWKS before claims() exposes those claims.

createServerSideApplicationSession represents your application’s own session store. Use the validated, application-scoped sub as the user key, keep any refresh token on the server, and send the browser only your application’s session cookie. Do not serialize the returned token response into that cookie.

Token verification reminder

Section titled “Token verification reminder”

OIDC ID tokens are verified against the JWKS at oidc.sudomimus.com/.well-known/jwks.json — that’s the standard OIDC mechanism, and your library does it for you.

The access_token returned by /token does not use the platform-wide OIDC JWKS. It is a per-application access token of the same shape as the Connect flow: payload sub is the pairwise user key, sid is the ApplicationSession, and jti is this token instance. Verify it by kid against https://session-api.sudomimus.com/applications/{applicationAnchor}/jwks.json. If your OIDC library cannot use a separate JWKS for access tokens, treat the access token as opaque and use /userinfo for claims. See Tokens and verification.

Pure Implicit

Section titled “Pure Implicit”

Enable id_token or id_token token explicitly in the client’s allowedResponseTypes and allow the implicit grant in allowedGrantTypes. For applicationType="web", every registered callback URI must use HTTPS without localhost or loopback hosts. Native clients use registered custom schemes or exact HTTP loopback URIs; HTTPS is rejected. Send a nonempty nonce, and validate it in the returned ID Token along with its signature, issuer, audience, and expiry. Implicit defaults to fragment delivery and accepts form_post, never query. PKCE inputs are ignored. offline_access is removed before consent; no refresh token or authorization code is returned.

id_token returns only an ID Token with permitted scope-requested identity claims. id_token token also returns an access token, token_type, expires_in, and granted scope; verify its at_hash in the ID Token. Both responses carry iss and the original state when supplied. A new authorization is required after expiry. The code-flow walkthrough above remains the recommended starting point; check deployed discovery before enabling either Implicit type.

Hybrid

Section titled “Hybrid”

Register the desired Hybrid response type explicitly and allow both authorization_code and implicit in allowedGrantTypes. Web clients require HTTPS callbacks without localhost or loopback hosts. Native clients use the native redirect policy described above. Hybrid defaults to fragment and also accepts form_post; query is rejected. Every code-bearing public client uses PKCE S256. A front-channel ID Token requires a nonce that the RP validates.

  • code id_token returns a code and ID Token with c_hash. Exchange the code normally; eligible offline_access still requires explicit consent. The ID Token uses the folded access-token TTL, independently of the short code expiry.
  • code token returns a code and AT. Exchange creates no second session and returns AT and IDT against the same non-refreshable session.
  • code id_token token adds an authorization ID Token with c_hash and at_hash. Verify both against the exact returned code and AT before use.

AT-bearing Hybrid removes offline_access before consent and never issues a refresh token. Code exchange does not extend the session lifetime. Its ID Token contains at_hash for that exchange’s AT and no c_hash. Validate iss, state, signatures, audience, expiry, nonce when supplied, and companion hashes at their respective boundaries. An authenticated code replay revokes the exact session, including live use of the earlier AT. Retry failed authorization by starting a new flow. Confirm deployed discovery before selecting a Hybrid response type.

Form Post callbacks

Section titled “Form Post callbacks”

Request response_mode=form_post for any of the six supported response types. Your registered callback must use HTTP(S) and accept application/x-www-form-urlencoded POST bodies and validate state and iss before processing the returned artifacts. Validate ID Token signature, audience, expiry, nonce, and applicable at_hash and c_hash; exchange a returned code through /token.

The provider submits an HTML form automatically and shows a Continue button when automatic submission is unavailable. Keep the response and callback body out of logs. If your RP correlates authorization using a cookie, configure that cookie with SameSite=None; Secure for cross-site POST delivery. Explicit SameSite=Lax and SameSite=Strict cookies are not sent on that callback.

Controlled dynamic registration

Section titled “Controlled dynamic registration”

For complete requests and responses, see Dynamic registration API. For issuance and revocation, see IAT and RAT management.

Use the discovery document’s registration_endpoint. Registration requires an Initial Access Token (IAT).

  1. As an organization OWNER, open With → Organization → Sector → OIDC and request approval for the RP’s host. Sudomimus staff approve the host. A pending request does not grant registration authority.
  2. On the same Sector OIDC page, issue an IAT. Select an active browser-ready application template, expiry, finite quota, permitted scopes and flows. Explicitly delegate activation of the new clients.
  3. The RP sends the IAT as a Bearer credential to POST /register.

Send an authenticated JSON POST /register with redirect_uris and the desired standard metadata. Defaults are response_types=["code"], grant_types=["authorization_code"], application_type="web", pairwise subjects, RS256 ID Tokens, and token_endpoint_auth_method="client_secret_basic". private_key_jwt requires public RSA jwks or an HTTPS jwks_uri; keep the private key at the RP. Unsupported algorithms and encryption are rejected.

A successful response is HTTP 201 and contains a ready client, its client_id, registration_client_uri, and a separate Registration Access Token (RAT). Shared-secret clients also receive a client_secret. Keep IATs, RATs, and client secrets out of browser storage, URLs and logs. The RAT can read current metadata and the current shared secret using GET registration_client_uri; it cannot edit registration metadata or create user sessions. It can delete its own OIDC registration with DELETE registration_client_uri. This disables the application but retains it as a management resource. Reads are audited and no-store. Use the With portal to edit rules or public keys. An OWNER can revoke a capability, replace a RAT, or revoke organization registration authority. Revoking/exhausting an IAT does not revoke previously registered clients or RATs.

An RP can register an optional HTTPS initiate_login_uri without a fragment. It identifies the RP endpoint that accepts third-party login initiation by GET and POST. The RP checks iss and starts a normal authorization request. The registration response and RAT read return this URI when it is configured. The With portal shows it as read-only. Contact Sudomimus support to set, replace, or clear it for an active dynamic registration.

Multiple redirect hosts require an HTTPS sector_identifier_uri document containing every exact redirect URI. Its host must already be approved for the organization’s Sector. Updating redirects revalidates the same placement and current document. Native clients may register custom schemes or exact HTTP loopback addresses; web clients enabling Implicit/Hybrid require HTTPS callbacks without localhost. A native custom scheme does not support browser Form Post.

Registered client names follow the platform naming policy. Submitted legal and homepage URLs are shown as descriptive links. Logos must be small PNG/JPEG/GIF/ WebP images (64 KiB each); the provider captures them safely so consent pages do not contact the RP image server from the user’s browser.

Signed authorization requests

Section titled “Signed authorization requests”

See the executable example in Advanced OIDC and capabilities and configure RP keys and rotation.

When discovery advertises Request Objects, clients configured for RS256 may send a signed JWT using request, or an HTTPS reference using request_uri. Supply outer client_id, response_type, and scope containing openid. Inside values override other outer parameters; inner client/type values must agree if present. The JWT may provide the redirect URI. Optional iss, aud, exp, nbf, and iat are validated when supplied. Unsigned/encrypted or nested objects are rejected. A nonempty registered request_uris list restricts usable references; otherwise a signed object may be fetched from any permitted public HTTPS destination. RP key rotation and normal registration changes remain live authority barriers. Check deployed discovery for available capabilities.

Further guides

Section titled “Further guides”