Thanks for clarifying abta.
Here’s a potential model of how you could architect this. This may/may not fit your security profile. I’ve tried to show separation of the unauthenticated registration flow functions from the main admin service which has all the super powers.
An unauthenticated registration API could get probed and poked a lot from the internet for security vulnerabilities. This model may help limit the blast radius were it to be breached.
I’ve also tried to illustrate the different scopes which would be in action for each of the different clients. My initial reply talks about where in Okta you’d configure these. Your mileage may vary - this may / may not be a suitable architecture for your situation.
As part of this you may wish to establish a common naming approach for your Organisation’s custom scopes (if you don’t have one already).
Hope this is clearer. 'night! Adrian
