We have an internal service application, and we want to programmatically verify if our engineers are part of a certain Okta group before we let our engineers perform certain actions through our application.
If we want to use Okta API internally, then any of our internal engineers has the potential to misuse the Okta Client because they can essentially clone the repo, and run a query internally through the codebase for any user and be able to view that user’s sensitive info.
Is there anyway we can restrict the okta client from returning sensitive info (password, address, etc) from a user object, or are there any permissions that will restrict info for any Okta account so that we can only view the bare minimum of the user, such as Name, Email, and what Groups they are a member of and exclude sensitive info?
Not fully understanding what you need, but you can play with attributes in Profile Editor and mark some attributes as hidden. Then they won’t be included into Users API response object for a user
I’ll agree with @phi1ipp about needing more information but this is a question I see in classes so this architecture may be what you are looking for:
Build a web service as a “trusted” server-side application using an API token to make your API requests. The API key should never be pushed into any code repo, in fact it would be a good idea not to let development groups access every repo you have, so these engineers shouldn’t be able to look anyways. Even the engineers that support this service shouldn’t have the API token, they should test against a development org and only the production administrators should have access to the production API token.
Have your service application make requests against this web service which can control what data they see. Instead of trying to use group membership to control what the web service lets them see through the service application, I would use an OAuth 2 access token and scopes to tell the web service what is allowed. Group membership on the Okta side can be used to control what scopes the authorization server in Okta allows for a particular user. Scopes translate into claim data in the access token, which the web service can read and controls what it allows.
Even if they fork and change the application they can see, still nothing can happen.