Dynamic Client Registration Permission Required

Question: Would like to create/manage clients through dynamic client registration API.
1, There will be a custom auth server for programmatic way of scope creation and association with a client (application type = service).
2, I would like to limit the access only for the applications created by this user/client (instead of giving access for all clients in okta).
3, I assume the DCR endpoints to be default auth server (this is acceptable)

Option 1: Using APIKey and assigning “Application Administrator” role to the user, able to create clients using DCR APIs. But it will have permission to all clients created in Okta (I can limit the apps for the user, but this requires again super admin permission to do the assignment). Is there any custom role, i can create to automatically limit the user to his own created clients ?

Option 2: Accessing Okta API using OAuth2 access token. Providing the scope “okta.apps.manage okta.clients.register” doesn’t even allow to create a client using DCR Apis. Is there any specific scope for client regiteration ? (a the above gives, 403 Forbidden, “The resource owner or authorization server denied the request.”)

Any suggestions,

As per our API docs for Dynamic Client Registration, the OAuth scopes for this endpoint are okta.clients.read, okta.clients.manage, and okta.clients.register.

Also, as seen in the docs, you will be making these requests to the Org Authorization Server, https://oktaDomain/oauth2/v1/clients.

@andrea , I have tried the following request, which includes the scope for okta.clients.read , okta.clients.manage , and okta.clients.register .
But I am getting 403 Forbidden error. Thanks for your help

curl --location ‘https://dev-24783725.okta.com/oauth2/v1/clients
–header ‘Content-Type: application/json’
–header ‘Accept: application/json’
–header ‘Authorization: Bearer eyJraWQiOiI3LTB4SEVBa2d1Wk1uUmd3ZmdZS2dfVzcxdG1raENoa3N6bnFwV1pDeUFVIiwidHlwIjoiYXBwbGljYXRpb25cL29rdGEtaW50ZXJuYWwtYXQrand0IiwiYWxnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULlNoYkVJMnVjMTdTOEczUVpWUFJiYWpqYUZsSjI2MEI4dXN5dFFTT2FJTHMiLCJpc3MiOiJodHRwczovL2Rldi0yNDc4MzcyNS5va3RhLmNvbSIsImF1ZCI6Imh0dHBzOi8vZGV2LTI0NzgzNzI1Lm9rdGEuY29tIiwic3ViIjoiMG9hZ3UyeDFsend0cVBOclM1ZDciLCJpYXQiOjE3MTUwMTgwMjgsImV4cCI6MTcxNTAyMTYyOCwiY2lkIjoiMG9hZ3UyeDFsend0cVBOclM1ZDciLCJzY3AiOlsib2t0YS5jbGllbnRzLnJlZ2lzdGVyIiwib2t0YS5jbGllbnRzLm1hbmFnZSIsIm9rdGEuY2xpZW50cy5yZWFkIiwib2t0YS5hdXRob3JpemF0aW9uU2VydmVycy5tYW5hZ2UiXX0.e-sb9fmLTsCg44D21IB8h5tADwA3XY9v566W2SYigUtEeN2M_JSsYgiMOwG7vb0MObd89lZZqeGrh5owANDQzej4Edf2csq2KM2nx0SBHMs-1AhtRPaGe4AkLrtDe4sjwkv_e6wsNaOqLT0_RWKiY_wMR57DJA6dIenq3iQTFB-3Gy7rf4XOIjD3s9_6dwCjHX7uJV_SCyEg0hn5mAXveTMA38K5oIXwl1WgTOis7GvZeusd4AiQtJzBuCWimUHddrabgl1RDEJ6zG_47K3KniXuYE8SkmDvHaa0d0egTWv8ljSEBzjNFw_PxA1EcFwi5050ab3zp4zxUoMMFosfaA’
–header ‘Cookie: DT=DI1bBFn59RsQ6Gj-3oyXkUjrw; JSESSIONID=D1B28B4BDD0879143C3262DF27768ACB’
–data ‘{
“client_name”: “API-sample-client”,
“client_uri”: null,
“logo_uri”: null,
“redirect_uris”: ,
“response_types”: [
“grant_types”: [
“token_endpoint_auth_method”: “client_secret_basic”,
“application_type”: “service”

Response: 403 Forbidden
{“error”:“access_denied”,“error_description”:“The resource owner or authorization server denied the request.”}

What admin role(s) did you assign the API Service app you are using to authorize this request?

I have not assigned any admin roles to API Service app to authorize this request.
If I assign “Application Administrator”, it works, But if I provide this, then it has access for all apps (irrespective of apps created by this client)

@andrea ,
Here the concern is this “API Service app who authorize the request”, will be able to generate credentials for any app in org and even delete any app in org. If we have an option to limit the privileges only to the app created by this “API Service”, it will be good for isolation.

Hm, the only option I can think of would be to grant an admin role to a specific list of applications, but I don’t see a way to have the list of apps they can manage be dynamically determined based on the apps they themselves created.

I do see some relevant requests on our Okta Ideas site that you likely want to track and add comments on:

  • Idea #185202: Add a Create X Admin role that allows to create and manage X resource
  • Idea #163826: Granular app admin permissions

Thanks @andrea for support

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.