No perfect options, but a few workarounds possible

a connector-like proxy which would intercept Client Credentials requests from their customers and use business logic to validate the client secret against the stored Duende hash. stand up a simple proxy in front of the Duende that logs the plaintext client secrets for a period of time before migration (protect these logs of course) go to each client and ask them to use a new FusionAuth specific client secret (analogous to resetting user passwords)

More details on the first option. It requires these steps/prereqs:

FusionAuth Entities Setup The customer should create new FusionAuth Entities that correlate to the Client ID of all APIs and services currently associated with Duende. For now, let FusionAuth generate a random Client Secret. Custom Attribute for Migration: Store a custom attribute such as migration: false on entity.data for all newly created Entities. Migration Steps API/Service Requests Token: The API or service calls Duende's token endpoint. Proxy Interception: The customer's proxy intercepts the client credentials request and searches FusionAuth Entities to find the matching Entity by Client ID. Migration Check: Use an if/else logic to check if migration: false exists for this client ID. If so, the proxy service proceeds with the client credentials request to Duende using the Client ID and Secret (in plain text). JWT Validation: If Duende responds with a JWT, this confirms the Client Secret is correct. The proxy service discards Duende's JWT and then calls the Entity API to update the correct Client Secret and set migration: true on the entity.data object. Complete Migration: The proxy service calls FusionAuth's token endpoint to complete the Client Credentials grant. The proxy service then returns a JWT to the end customer’s API/service, migration is complete.

Which of these make sense depend on how many clients you have, your dev teams bandwidth, and your security posture.

@arjunyel

Connectors are documented here: https://fusionauth.io/docs/v1/tech/connectors/

Machine to machine auth is the client credentials grant: https://fusionauth.io/docs/v1/tech/oauth/#example-client-credentials-grant

Does 100 Machine To Machine Auth mean you can have 100 API entities?

Yes, that is correct.

@nikhil-shrivastav

Thanks for the question. I have addressed in our support other related support thread.

Thanks
Josh

I'd use a webhook to provision/deprovision the grants.

https://fusionauth.io/docs/v1/tech/events-webhooks/events/user-registration-create-complete/ has the roles for the application, so in the webhook, you can call the FusionAuth grant API to create or revoke the grant.

For initial setup, run a script to get all the users that have a given role (using a user search query) and then grant them access to all the entities.

Think about what happens when a new piece of equipment is added. From what I gather, all users with the "viewer" role will need to be granted access to that equipment. You can take care that of within the 'new equipment added' script: provision the equipment, then add the grant to all users with the "viewer" role.

Depending on when you are going to check the grant and the number of users and pieces of equipment, this may be a good thing to use a queue like SQS for, to add/revoke/update grants asynchronously.

The ability to search grants for a user was a gap in our documentation. We have since released an update to showcase/describe the use case.

https://fusionauth.io/docs/v1/tech/apis/entity-management/grants/#search-for-grants

Your API endpoint call will look like below:

GET /api/entity/grant/search?userId={uuid}

Additional possible filtering functionality is documented in this feature request.