If you have a single service performing multiple operations, you could consider a single Okta application with the relevant Okta API scopes to do this. This is configured in the “Okta API Scopes” tab of the applicaiton in Okta.
A reason to separate these could be to segregate user publically accessible functions you don’t have to authenticate to like registration from those functions you must authenticate to use like update/delete/etc.
If you decide to decompose the service into multiple services, then consider setting up multiple Okta apps so it is clear in the Okta system log which service is doing what in Okta. This will help with troubleshooting and auditing.
You’ll want to protect your new service with an API gateway and Okta + API scopes. The parts you need to authenticate to access should have a policy where you can’t access them without a token. To use Okta to manage access to your service, then you’d likely want to define your own scopes in a new authorisation server (Security > API). You’ll probably need a custom auth server as the default auth server has constraints (Authorization Servers | Okta Developer).
Setup additional application(s) which represent the Client Service. Setup policies in the new auth server (Security > API) so access to the non-public admin service should be protected and you should only be able to access them with a valid token with the correct scopes.
Consider other API security measures at your API gateway / network provider to prevent security attacks, implement rate limiting, prevent DDOS, etc. Your security team should be able to advise.
I’m sure others in the forum will have some good alternative approaches. If you can share more of the context (is this on the internet? For staff or external users?) there’s likely alternatives.
Hope this helps,