Let compatible tools register themselves

An outside tool submits client details, receives a client ID through registration, then proceeds to consent.

Let compatible tools register themselves

A tool without a pre-created client ID can register before starting a user-approved connection. Wildo offers this as an application choice, with limits on what an unauthenticated registration can obtain.

Registration supplies an identity for the tool; it does not give the tool independent access to business data.

Example — Connect a tool that needs a registration endpoint

The application enables registration. A tool supplies its name and safe redirect URI, receives a client ID and continues through the person’s consent and PKCE flow.

For engineers

Configure auth.dynamicClientRegistration. It is disabled by default; when disabled the endpoint returns 404 and discovery does not advertise it. The default limit is ten registrations per source IP per hour.

In the backend-authored application’s auth section, enable the public door and choose a rate ceiling. These are the fields declared by DynamicClientRegistrationConfigSchema:

dynamicClientRegistration: {
  enabled: true,
  maxRegistrationsPerHourPerIp: 10,
},

The public endpoint checks that an incoming registration is not asking to grant itself business roles:

This implementation excerpt from oauth-provider-controller.backend.service.ts shows the decision in context; explanatory source comments are omitted.

if (body.roles !== undefined) {
      this.sendRegistrationError(res, 'invalid_client_metadata', 'roles cannot be requested at dynamic registration');
      return;
    }
    const requestedScopes = typeof body.scope === 'string' ? body.scope.split(/\s+/).filter(Boolean) : [];
    const beyondIdentity = requestedScopes.filter((scope) => !OIDC_SUPPORTED_IDENTITY_SCOPES.includes(scope));
    if (beyondIdentity.length > 0) {
      this.sendRegistrationError(res, 'invalid_client_metadata', `scope(s) not available to a dynamically registered client: ${beyondIdentity.join(', ')}`);
      return;
    }

Register a public authorization-code client

Send the tool’s client_name and non-empty redirect_uris to /oauth/register. Redirects must pass the safe-URI policy: HTTPS, or permitted loopback HTTP, without embedded credentials or fragments. The returned client metadata describes what was actually registered.

Requested authority	Registration behavior
Business roles	Refused
Non-identity scopes	Refused
Client-credentials grant	Refused
Authorization-code flow	Public client using PKCE and consent
Requested refresh grant	Not granted; returned metadata reflects the narrower grant set

For example, a tool can register the following illustrative HTTPS callback. Replace the example URL with the tool’s actual callback and BACKEND_URL with the application’s backend:

curl "$BACKEND_URL/oauth/register" \
  -H 'Content-Type: application/json' \
  --data '{
    "client_name": "Customer workspace tool",
    "redirect_uris": ["https://tool.example/callback"],
    "grant_types": ["authorization_code"],
    "token_endpoint_auth_method": "none",
    "scope": "openid profile email"
  }'

A successful response is HTTP 201 with client_id and the accepted metadata. It also returns a one-time registration_access_token and registration_client_uri for managing that registration. Store them securely: the management token is distinct from an OAuth client secret and does not authorize business API calls.

No OAuth client secret is returned. The tool uses client_id to start authorization with PKCE and user consent; it acts for that person rather than as an independently privileged machine.

Choose the onboarding policy for your audience

Enable this for clients that need the registration mechanism. Client metadata documents provide another identity-onboarding path. Neither mechanism bypasses consent, resource-audience checks or the person’s operation permissions.

Let compatible tools register themselves