New to Okta, and I am trying to figure out what the design/approach should be in my case. We are planning to create service (e.g. AdminService) that will sit between Okta and other services.
The AdminService will expose multiple operations to create/update/delete/activate/deactive users, enroll MFA etc. Operations in AdminService can be allowed/restricted based on the Client service.
Other Services → Admin Service → Okta
I am not sure on how/where the authorization needs to be configured. I have read Okta document to configure scopes on application level as well as the Authorization level. Not sure when to prefer one over the other.
Should I be configuring multiple Okta application each specifying scope for each and every Client ? or do I need to configure multiple Authorization server specifying scope for each and every Client ?
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.
When you say ‘internal’ and ‘external’, do you mean services that are inside or outside of your company’s network?
What I was trying to get at is some of your identity APIs must be public by their nature - like registration. Registration can’t be authenticated as you don’t know who the end user is yet - assuming the client app here is something like a Single Page App (SPA) or mobile app which an end user is directly interacting with. Another could be forgotten password.
Pretty much all other operations must be then private and only accessible to a previously registered user who has authenticated.
Yes, by internal I mean internal services or applications e.g. Customer Support/Service, and external will be Customer facing app (internet)
In case of user registration the flow will be like
Customer facing app → Admin Service → Okta, here the Customer facing app will call the Admin Service to create a user on Okta.
Similarly, the Customer Service app can create the user.
Customer Service app (internal) → Admin Service → Okta, here the Customer Service app will call the Admin Service to create a user on Okta.
Since the Admin service is used by both Customer facing app and Customer support app and possibly more app/services, the AdminService exposes or have operations which for e.g the Customer facing app should be restricted to for e.g. deactivate user, which should only be allowed from Customer Service app.
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).
