While ArcGIS Enterprise nominally supports the client_credentials OAuth2 flow, its behavior is highly non-standard. In fact, it turns out the app must be owned by the same user as the resources it can access. This is not ideal. There is documentation that outlines this restriction and why it exists.
However, the standard behavior for this type of application or service user (client) would be for the application to have its own access privileges instead of assuming those of its owner. The client could be granted permission to a single service from a user who has published many services. It could be granted permission to access services published by different users. The owner of the client should be able to rotate the client secret.
Let's outline a scenario:
Publisher A works on projects with a variety of clients in a large enterprise organization. They have several services they publish, including a tax parcels service and a custom geocoder.
Client B wants to use the custom geocoder in their application. The organization's security policy specifies that API keys should be rotated every 90 days.
Client C wants to use the tax parcels service and the custom geocoder in their application as part of a weekly validation routine on some of the data Client C works with. The process takes a while, and runs automatically overnight.
Under the existing ArcGIS Enterprise behavior, Publisher A needs to create two API keys. They will then share the secret information with Clients B and C, including the quarterly rotation for Client B. These API keys will have access to all the services that Publisher A owns. The security team is not thrilled by this arrangement.
A better method would be for Clients B and C to create API keys (B-app and C-app), and for Publisher A to grant those API keys access with appropriate permissions levels to the geocoder service (for both B-app and C-app) and the tax parcel service for C-app.
Because Client B owns the B-app API key, they can rotate the key when they need to (client_id being constant and what is tied to the permissions). Their API key can only access what it needs to.
Similarly, Client C owns the C-app API key, and can also rotate the key when they need to. Their API key can access the services it needs with the permissions it needs, but doesn't assume the permissions of its owner.
Clients B and C are happy, because their applications can get the data they need in a fully automated way. The security team is pleased that the applications have the least privileges needed, and that secrets don't need to be shared between Publisher A and Clients B and C. Publisher A is happy that they don't need to be involved when a client needs to rotate their API key, and that they can keep their clients from having the full access to many datasets that Publisher A has.
