Can we create a master Okta App which can create apps in other orgs

Is there a way to configure a master app in Okta in one org which can create apps in another orgs by getting some user/admin consent?

Any suggestion on this?

Basically, we are trying to understand that if Okta supports a flow in the way Azure handles the muti tenant app. In Azure, we can create a master App in one provider tenant, and then an admin of a customer tenant can add this master app to their tenant through the admin consent flow. Now using this master App, we can create a new dedicated app in the customer tenant.

No, this is not a use case that Okta supports. You cannot access/create apps in another tenant, but you could make an app and submit it to the OIN so that other orgs are able to easily add it to their org.

Thanks, @andrea.

I have gone through the OIN and I have a few queries on that.

1: Can we create a service App as an OIN app. We basically need an app with permissions to call APIs to get information such as user/logs etc.

2: If a tenant adds the OIN app to their app catalog then is there an Okta recommended way to pass this app’s client credentials to the provider of the OIN app so that the provider can start calling the APIs using this newly added app.

  1. No, we only accept Web and Single Page OpenID Connect applications into the OIN
  2. We don’t have specific recommendation for how to achieve this, just that you will need to supply some sort of way for your customers to provide these client credentials to you. I often see this via some sort of integration portal on the SP side or some other mechanism by which they can send you these credentials. You can review a example integration guide here and here to see how some providers are handling this:

Hi @Pradeep-Durgapal,

We are now working on a way to submit a service app through the OIN. Are you interested in this? If so, I can give you more information. You can email oin@okta.com, and I can reply to you there.

Using this new capability, you would be able to use a client id and secret to access the API through a client credentials flow. You would need to collect this from each customer / Okta org administrator.

Thanks,
John

1 Like

Although confusingly name, the Default Authorization Server is also a custom one.

Make sure you use your Org Authorization Server instead (e.g., your requests should be going to https://oktaDomain/oauth2/v1/token NOT https://oktaDomain/oauth2/default/v1/token)

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