Registering a Client

Via Admin UI

Go to Admin UI → Clients → Create Client. Fill in the required fields and click Create. The UI generates client_id and client_secret (for confidential clients) automatically. Save the secret immediately — it is only shown once.

Only response_types: ["code"] is supported. Registration and update reject implicit (token), ID-token-only (id_token) and hybrid response types. The Admin UI offers only Code. Existing registrations cannot enable an unsupported flow: authorization returns unsupported_response_type instead of issuing a code for another response type. When editing a legacy registration, remove unsupported response types and explicitly select Code before saving; the form explains the required repair and does not enable Code automatically. Authorization also requires the client’s authorization_code grant, including during SSO.

The create form defaults to a public client with authentication method None. Changing the client type selects a compatible authentication method; the create and edit forms offer only methods that match that type.

Authentication metadata and existing clients

client_type is an optional Autentico extension. A request with token_endpoint_auth_method: "none" and no client_type registers a public client without issuing a secret. If both fields are omitted, registration defaults to a confidential client with client_secret_basic.

Client type	Authentication method
Public	`none` (also the default when the method is omitted)
Confidential	`client_secret_basic` (default) or `client_secret_post`

Registration and update reject contradictory combinations with HTTP 400 invalid_client_metadata. Updating authentication metadata does not change the registered client type.

Older versions could store contradictory metadata. After upgrading, read/list responses report the effective method: a confidential client labelled none reports client_secret_basic, while a public client reports none. Existing confidential clients keep their secrets and continue to require them. No database migration or secret rotation is required. Saving an existing client repairs the stored method while preserving its type, secret and active/disabled status. To replace a confidential registration with a public one, explicitly register a new public client and update your application’s client ID.

curl -X POST https://auth.example.com/oauth2/register \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "My SPA",
    "redirect_uris": ["https://app.example.com/callback"],
    "grant_types": ["authorization_code", "refresh_token"],
    "response_types": ["code"],
    "client_type": "public",
    "token_endpoint_auth_method": "none"
  }'

curl -X POST https://auth.example.com/oauth2/register \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "My Server App",
    "redirect_uris": ["https://app.example.com/auth/callback"],
    "grant_types": ["authorization_code", "refresh_token"],
    "response_types": ["code"],
    "client_type": "confidential",
    "token_endpoint_auth_method": "client_secret_basic"
  }'

Response:

{
  "client_id": "a1b2c3d4-...",
  "client_secret": "sk_live_...",
  "client_secret_expires_at": 0,
  "client_name": "My Server App",
  "client_type": "confidential",
  "redirect_uris": ["https://app.example.com/auth/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "client_secret_basic"
}

Fields

`client_name`

Required.

Human-readable name for the client, shown in the Admin UI and logs.

`client_id`

Custom client ID. Auto-generated (UUID) if omitted. Must be unique across all clients.

`client_type`

Default: public when the requested authentication method is none; otherwise confidential.

confidential — server-side apps that can keep a secret. A client_secret is generated and must be presented at the token endpoint.
public — browser apps (SPAs) or mobile apps that cannot safely store a secret. No secret is issued; use PKCE instead.

See Client Types for details.

`redirect_uris`

Required.

Array of allowed callback URLs, with a maximum of 10 URIs per client. Exact registrations require byte-for-byte matching, including their query strings. Prefer concrete callback URLs in production, as required by RFC 9700 exact-match guidance.

For test callbacks with a variable identifier, an explicit compatibility extension permits one * as a whole path segment, for example https://rp.example/test/*/callback. It matches one nonempty plain identifier using only letters, digits, -, ., _ and ~, excluding the complete segments . and ... run-123 matches; nested paths, percent-encoded values, backslashes, queries and fragments cannot replace the wildcard.

The OpenID Foundation suite uses /test/a/<ALIAS>/callback. Register the exact chosen alias URL, or use the bounded /test/a/*/callback pattern when testing multiple aliases. See the official conformance setup guide.

The scheme, host, port, remaining path and any registered query string must match literally. Host/query wildcards, partial-segment wildcards and multiple wildcards are rejected. A root pattern such as https://rp.example/* matches one component, such as /run-123, rather than an arbitrary nested path. Existing broader patterns no longer match and should be replaced with explicit callback URLs or this bounded form.

`grant_types`

Default: ["authorization_code", "refresh_token"]

OAuth2 flows the client is permitted to use:

Value	Description
`authorization_code`	Standard browser-based login flow (use with PKCE for public clients)
`refresh_token`	Exchange a refresh token for new access tokens
`client_credentials`	Server-to-server authentication (no user involved)
`password`	Resource Owner Password Credentials — direct username/password exchange. Legacy; avoid for new integrations

`response_types`

Default: ["code"]

What the authorization endpoint returns. Only ["code"] is supported; implicit and hybrid response types are rejected.

`scopes`

Default: openid profile email

Space-separated string of scopes the client is allowed to request. Standard OIDC scopes: openid, profile, email, address, phone, offline_access. Custom scopes can also be defined.

`token_endpoint_auth_method`

Default: none for public clients; client_secret_basic for confidential clients.

How the client authenticates at the token endpoint:

Value	Description
`client_secret_basic`	Credentials sent as HTTP Basic auth header (recommended for confidential clients)
`client_secret_post`	Credentials sent in the POST body
`none`	No authentication — for public clients using PKCE

`consent_required`

Default: false

Boolean. When true, the user is shown a consent screen to approve the requested scopes before an authorization code is issued. Consent is remembered per user+client+scope combination — subsequent logins skip the consent screen unless the requested scopes change.

`post_logout_redirect_uris`

Default: []

Array of URIs the client may redirect to after RP-initiated logout. The post_logout_redirect_uri parameter in a logout request must exactly match one of these values.

Account dashboard fields

These fields control whether and how the client appears in the Applications section of the user account dashboard (/account). Signed-in users fetch the list from GET /account/api/apps.

Field	Default	Description
`show_in_account`	`false`	List this client on the account dashboard. The built-in `autentico-admin` and `autentico-account` clients are never listed.
`client_uri`	`""`	Application home page, used as the Open link. RFC 7591 client metadata.
`logo_uri`	`""`	Image shown next to the application name. RFC 7591 client metadata.
`description`	`""`	Short text shown under the name. Max 1000 characters, no `<` or `>`.

client_uri and logo_uri must be https URLs; http is accepted only for localhost, 127.0.0.1 and [::1]. On update, send "" to clear a field; omitted fields are left unchanged.

See Per-Client Configuration for fields that override global settings.