O Auth Client Register
RFC 7591 OAuth 2.0 Dynamic Client Registration. Ordinary Authorization Code clients are tenant-owned and must use PKCE. Only an explicit grant_types: [client_credentials] request provisions a bot account and a separate OAuth client atomically, with client_name as its handle. It requires private_key_jwt and public JWKS. Mixed autonomous and delegated grants are rejected. Delegated private_key_jwt clients create no account. Autonomous clients inherit the bot account's current role permissions. Client credentials token requests without scope receive those permissions; explicit token scopes may narrow them. The optional runtime setting services.oauth.autonomous_registration_role_id assigns an additional role atomically at provisioning; deleted role references are skipped. Autonomous registration is controlled by the runtime setting services.oauth.autonomous_registration_mode: disabled rejects it, protected requires an Initial Access Token in Authorization: Bearer, and open permits it without a token. Supplied tokens must always be valid and authorize autonomous registration only. One use is consumed atomically with successful account and client creation. Invalid metadata or handle collisions do not consume a use. Ordinary DCR does not require an IAT. This endpoint is rate limited. In approval mode, a valid IAT permits immediate registration. Otherwise, autonomous clients must opt in with registration_mode: [approval] and receive 202 with a registration_code and verification challenge. Poll this endpoint with registration_code; metadata supplied on a poll is ignored. Approval returns 201 on a subsequent poll. Early polls return 429 with Retry-After. Denial, expiry, and unknown or consumed codes return 400. Send registration_code and cancel_registration: true to cancel a pending request (204). No account or client exists while approval is pending. Implements draft-dellaert-oauth-approval-based-dcr-00 (experimental).
/oauth/registerRFC 7591 OAuth 2.0 Dynamic Client Registration.
Ordinary Authorization Code clients are tenant-owned and must use PKCE. Only an explicit grant_types: [client_credentials] request provisions a bot account and a separate OAuth client atomically, with client_name as its handle. It requires private_key_jwt and public JWKS. Mixed autonomous and delegated grants are rejected. Delegated private_key_jwt clients create no account. Autonomous clients inherit the bot account's current role permissions. Client credentials token requests without scope receive those permissions; explicit token scopes may narrow them. The optional runtime setting services.oauth.autonomous_registration_role_id assigns an additional role atomically at provisioning; deleted role references are skipped.
Autonomous registration is controlled by the runtime setting services.oauth.autonomous_registration_mode: disabled rejects it, protected requires an Initial Access Token in Authorization: Bearer, and open permits it without a token. Supplied tokens must always be valid and authorize autonomous registration only. One use is consumed atomically with successful account and client creation. Invalid metadata or handle collisions do not consume a use. Ordinary DCR does not require an IAT. This endpoint is rate limited.
In approval mode, a valid IAT permits immediate registration. Otherwise, autonomous clients must opt in with registration_mode: [approval] and receive 202 with a registration_code and verification challenge. Poll this endpoint with registration_code; metadata supplied on a poll is ignored. Approval returns 201 on a subsequent poll. Early polls return 429 with Retry-After. Denial, expiry, and unknown or consumed codes return 400. Send registration_code and cancel_registration: true to cancel a pending request (204). No account or client exists while approval is pending. Implements draft-dellaert-oauth-approval-based-dcr-00 (experimental).
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
RFC 7591 client metadata supplied by a dynamically registering client. All fields are optional; Storyden applies safe defaults and rejects metadata that requests unsupported grants, response types, redirect URIs or scopes.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/oauth/register" \ -H "Content-Type: application/json" \ -d '{}'{ "client_id": "string", "client_secret": "string", "client_id_issued_at": 0, "client_secret_expires_at": 0, "client_name": "string", "redirect_uris": [ "http://example.com" ], "grant_types": [ "string" ], "response_types": [ "string" ], "scope": "string", "token_endpoint_auth_method": "string", "application_type": "string", "logo_uri": "http://example.com", "client_uri": "http://example.com", "tos_uri": "http://example.com", "policy_uri": "http://example.com"}O Auth Client List GET
List OAuth clients created by the authenticated account. This is the member-facing "apps I created" view. OAuth clients are application definitions: client ID, client type, redirect URIs, allowed scopes, and allowed grants. This does not list built-in first-party clients or third-party apps the member has merely authorised. Use `/auth/oauth/tokens` for the "apps I have authorised" view.
O Auth Client Update PATCH
Update an OAuth client created by the authenticated account. Allowed scopes must remain within the authenticated account's current permissions. If the account has `ADMINISTRATOR`, it may configure any Storyden permission scope because `ADMINISTRATOR` implicitly grants all permissions. Changing allowed scopes affects future grants and refreshes but does not immediately invalidate already-issued JWT access tokens.