We have many APIs and services, which are accessed by humans and non-human identities (M2M), like ETL jobs, ML training jobs, backend services, dynamically registered mobile devices, which do not act on behalf of a human user. Currently we are using Client Credentials or dynamically create users in Auth0 and use the Resource Owner Password Flow. However, with the fast growing number of ETL jobs, ML training jobs and connected services in our organization the task and overhead of managing all the client credentials for all these non-human identities is cumbersome and time consuming. This results in hardcoded client credentials and reuse of client credentials for different jobs and backends, which should have their own non-human identity and permissions.
To solve this problem we would like to use the concept of service accounts. With this we mean having non-human identities as first class citizens in Auth0. Currently Auth0 is build to manage human identities very well. Non-human identities on the other hand can only be represented by Client Credentials,
There is no support for federation of non-human identities or integration of Identity providers for non-human identities.
For example, we run our workloads in kubernetes, which manages service accounts for each workload.
These service accounts represent the non-human identity of the workloads and can be federated via OIDC, to allow the workloads to authenticate themselves to (external) APIs. Each workload has access to an JWT token, which can be used as an ID Token by the workload. This means, instead of manually creating Client Credentials for each of the workloads in Auth0. The service accounts of the workloads should be federated via Auth0 to the accessed APIs.
Of course Auth0 can not provide such specific integrations and there are no standards on how to federate non-human identities. However, Auth0 should provide the necessary Management API to implement such an integration.
There should be an Auth0 Management API which allows to programmatically generate valid access/Id Tokens for federated non-human identities. Given that the Identity provider of the non-human identities (kubernetes) is a trusted party, it should be possible via a integration component to map these non-human identities to identities in Auth0 with appropriate access/Id Tokens for the non-human identity.
This is similar on how AWS assigns IAM roles to kubernetes service accounts, which is much easier and secure than creating static AWS access keys for all workloads which is also not best-practice.
From a security point of view it is better to use federation if possible that handling static secrets.