Dynamic clients

Registering an agent manually works when you know the agent in advance. A public Model Context Protocol (MCP) server usually doesn't: your customers bring their own agents, and most MCP clients expect to introduce themselves rather than be provisioned in advance. Dynamic client support closes that gap. An unknown agent discovers your Strivacity instance, identifies itself, and sends the customer through your Application's normal login and consent journey, with no admin involvement.

Strivacity supports dynamic clients through Client ID Metadata Documents (CIMD): the agent's client ID is an HTTPS URL pointing to a JSON metadata document the agent hosts. Strivacity fetches the document when the agent authorizes, and no client record is created.

Every Strivacity-side setting (the Application binding, protected resources, consent behavior, and token settings) comes from a single designated dynamic client template. The result is an authorized AI agent like any other: token audiences constructed from the assigned protected resources, activity attributed to the agent in account events, and consents the customer can review and revoke in the My Account portal.

Dynamic client support is currently limited to AI agent clients. The initial release focuses on compatibility with the MCP specification: authorization code with PKCE, and dynamic agents are always public clients.

The dynamic client template

A dynamic client template defines the configuration that every dynamic client receives. It lives under an Application, and that binding is its most important job: the Application determines the login journey, Adaptive Access policy, identity store, and branding your customers experience when an agent sends them to authorize through Strivacity.

A template is an AI agent client that you designate as a template when you create it; there's no separate client type. On the Application's Clients tab, select Create, choose either of the two AI agent cards (OIDC using no-code components or OIDC using the Journey Flow API), and turn on the Dynamic client template switch on the General tab. The switch only exists for the AI agent client subtype.

Turning the switch on transforms the rest of the form: the credential fields disappear, the callback URL list becomes callback URL rules, and the Application launcher tab is removed. You can also start from Agentic AI > Client registration, where Create template asks which Application to create the template under and opens the catalog narrowed to the two AI agent cards.

The card you choose determines how dynamic agents authenticate customers. A template created from the no-code card produces agents whose customers sign in through Strivacity's hosted login and consent pages; a template created from the Journey Flow API card produces agents that render the login experience natively through the Journey Flow API. External agents are generic OAuth2 clients that redirect to a hosted page, so the no-code variant is the expected choice for a public MCP server. The Journey Flow API variant is for dynamic agents that embed Strivacity's SDK, such as agents you create.

The template appears in the Application's Clients list with a TEMPLATE badge alongside its client type. It isn't a live client: it has no client ID or secret, can't authenticate, and never appears on a consent screen itself. An instance can hold several templates, but only the one designated as the Default template on the Client registration page is used, so all dynamic clients share one Application and one variant.

Template settings

The template form reuses the client editor's structure. Some fields hold values every dynamic client inherits:

• Protected resources: one or more assigned protected resource policies, with the same per-resource, per-scope consent configuration as a manually registered AI agent (allowed to request, required or optional, shown or automatically granted). Assigning at least one resource is mandatory: the agent's metadata document never names a resource, so the template has to pre-bind them. Token audiences are constructed from these resources, matched exactly per RFC 8707.
• Dialect and Require consent for scopes: as on any client.
• Token settings under Advanced: access token lifespan and format, and refresh token settings. A new template defaults to values that fit MCP agents: JWT format so resources can validate tokens locally, a 5-minute access token lifespan so consent revocation takes effect quickly, and refresh tokens enabled.

One field is a constraint that validates what agents present, instead of holding a single value:

• Callback URL rules replace the usual allowed callback URL list:
  • Allow HTTPS callback URLs (on by default).
  • Allow loopback callback URLs (on by default): http://localhost and http://127.0.0.1, with the port allowed to vary per the OAuth2 native-app best practice. Desktop MCP clients depend on this.
  • Allow custom scheme callback URLs (off by default), with an optional list of permitted schemes. An empty list with the switch on allows any scheme.
  • Plain http:// URLs other than loopback are always rejected.

Fields that don't apply to dynamic agents (client credentials, the Application launcher tab, logout URLs, and custom audiences) aren't on the form; a dynamic agent's display identity comes from its own metadata document. The Client subtype and the Dynamic client template switch stay visible but are read-only after save.

Template changes apply immediately

Dynamic clients don't copy the template; Strivacity reads it at authorization time. Editing the template therefore changes the effective configuration of the entire dynamic population at once: token lifespans, consent configuration, and assigned protected resources included.

The Client registration page

Agentic AI > Client registration holds the instance-level controls for dynamic clients:

• Default template: the dynamic client template that dynamic clients draw configuration from, listed as Application name / Template name with its client type shown. Client ID Metadata Documents can't be switched on until a default template is selected, and a template can't be deleted while it's the designated default.
• Enable Client ID Metadata Documents: accepts HTTPS URLs as client IDs. There's nothing else to configure; fetch behavior ships with fixed safe defaults (described below).

If the template's Application is disabled or deleted, the switch turns off and the page shows a warning banner.

The switch governs what Strivacity publishes and accepts:

How CIMD authorization works

With CIMD enabled, the authorization endpoint accepts a client_id that is an HTTPS URL. When one arrives, Strivacity:

1. Fetches the URL. Fetches are HTTPS-only with no cross-origin redirects, capped in size and time, and must return JSON. Documents are cached briefly; a failed fetch with no valid cached copy rejects the authorization with invalid_client.
2. Validates the document: its client_id must equal the URL, its redirect_uris must all pass the template's callback URL rules, and the request's redirect_uri must exactly match one of them. Only the authorization_code and refresh_token grant types and the code response type are accepted. CIMD agents are always public clients: the token endpoint authentication method must be none, and PKCE is required.
3. Applies the default template: the Application's journey, protected resources, consent configuration, token settings, and client type variant. A generic external agent can't drive the Journey Flow API, so CIMD pairs naturally with a no-code template.
4. Proceeds through authentication and consent as normal. The consent screen shows the document's client_name and logo, marked as unverified.

No client record is created at any point. Consents are recorded against the URL as the client identifier, and metadata changes on the agent's side flow through on the next fetch: a rename or a new logo appears automatically. If the document disappears, the agent can no longer authorize.

Because there's no record, there's also no CIMD client list and no per-agent kill switch. Instance-level control is the CIMD switch; per-customer control is consent revocation, in the My Account portal or by an admin. See Authorization consents.

Unverified agent identity

For a manually registered agent, a brand admin vets the display name and logo. For a dynamic agent, nobody does: the name and logo are whatever the agent's metadata document provides, and the consent screen is exactly where a spoofed name could mislead a customer. Strivacity shows the agent-supplied name and logo anyway (blanking them would leave the customer with less context, not more), but visibly marked as unverified.

• On the consent screen, the agent's name and logo carry an Unverified indicator with supporting text explaining that the identity was provided by the agent itself.
• The protected resource's display name and logo, which an admin did vet, anchor the screen, and the plain-language scope descriptions carry the decision weight. See Protected resources.
• The same marking appears wherever the agent's self-asserted identity shows: the My Account portal consent list and the admin consent views.
• Names are length-limited with control characters stripped, logos are fetched only over HTTPS, and a failed logo load falls back to a generic agent glyph.

Manually registered agents are unchanged; there's no "verified" badge, just the absence of the unverified marker.

Where dynamic agents appear in the Admin Console

AI agents list. Agentic AI > AI agents has a Registration column with the values Manual and Template, plus a matching filter; templates are AI-agent-subtype clients, so they belong in this list, and template rows open the template editor. CIMD agents don't appear here (no records); their footprint is in authorization consents and account events.

Consents. Dynamic agents appear in the My Account portal's consent list and in the Admin Console's account-level consent view exactly like manual agents, with the unverified marker on their name. The client identifier shown is the agent's metadata URL.

Account events. Agent activity is attributed as usual: the customer as the subject and the agent as the actor. For dynamic agents, the actor shows the document's client_name with the URL as the identifier.

Set it up

Before you begin, you'll need an Application with a configured login journey and your MCP server registered as a protected resource with its scopes described. See Protected resources.

1. On the Application's Clients tab, select Create and choose an AI agent client type. For a public MCP server, OIDC using no-code components is the usual choice.

You can also start from Client registration > Create template, which asks for the Application and narrows the catalog for you.

2. On the General tab, turn on Dynamic client template. The form drops the credential fields and swaps in the template's constraint fields. Remember that the designation can't be changed after you save.
3. Assign the protected resources dynamic agents may request access to, and configure per-scope consent behavior.
4. Review the callback URL rules and the token settings. The defaults fit MCP agents.
5. Select Save.
6. Go to Agentic AI > Client registration and select your template as the Default template.
7. Enable Client ID Metadata Documents.

Discovery metadata

With Client ID Metadata Documents enabled, https://BRAND_DOMAIN.strivacity.com/.well-known/openid-configuration additionally publishes client_id_metadata_document_supported: true.

Nothing else about the integration changes: your MCP server's protected resource metadata still names Strivacity as the authorization server, MCP clients still fall back to OIDC Discovery, and code_challenge_methods_supported is still published. The only difference is that the agent no longer needs to exist in your instance before it starts. See Integrating an MCP server with Strivacity.

Where to go next

• AI agents: manual registration, for agents that need bespoke configuration.
• Protected resources: the resources and scope descriptions the template binds.
• Authorization consents: the consent experience, including revocation.
• Integrating an MCP server with Strivacity: the developer-facing integration details.