We’ve recently been investigating using organizations as a prerequisite for being granted an M2M token.
Currently, we manage this by creating separate applications for each of our intended M2M clients. This means that we can lock down our own internal applications and external client applications by only telling them about the client ID/secret that is relevant to them.
Ideally, we would love to replace this system with a single M2M application and restrict access by organization. It would save us a bit of infrastructure management and more closely mimic what we do with our web applications and their login flow. While reading the documentation, it seems that when requesting an M2M token through the client credentials flow, the caller must provide the organization they wish to assume.
While this is fine for our internal applications, we’re hesitant to implement this model for our external customers. For instance, if a customer (represented by a single organization) obtained the organization information for an unrelated customer, they would be able to spoof a request as that organization.
Is there an out of the box way to “harden” this M2M organization request? I.e. is there a more secure way of locking down a customer to only be able to request M2M tokens to their organization? I can think of a few ways through the credentials-exchange action flow but I’m wondering if the effort spent there is worth the benefit, or should we simply keep our current setup the way it is?
To harden security for your M2M organization requests implement Enterprise Connections. By proving their organization identity it will make it harder for non members to spoof requests, and assuming the organization is logging their logins they will be able to track and potentially block suspicious login attempts.
If you have any other questions feel free to reach out.
Thanks for the response. Though I’m not sure that this fits our use case, since I believe the client credentials flow doesn’t require a connection, just supplying the client_id/secret as well as the organization.
I suppose we could have the machines mimic a user and authenticate using an enterprise connection, but at that point I don’t think we’re dealing with an M2M client credentials flow anymore, which would introduce additional hurdles.
Our solution that we’ve been playing around with has been using a custom “organization secret”, managed externally to Auth0, and then validating that against a custom parameter sent over in the initial client credentials token request. I’m mainly wondering if there’s something simpler that Auth0 offers without needing to switch our grant type.
You won’t need to provide a connection in the code of your application, it will be shown on the login page as a way to sign in for example with Okta Enterprise or Google Workspace. The connection will only be used to authenticate the user into his organization account and make sure that the user’s identity is bounded by the organization he’s a member of. This is the simpler and the recommended way of achieving the security you desire.