Auth0 M2M Pattern - how to identify the OnBehalfOfUser information

Hello team,

In the scenario of M2M Pattern, involving an external partner involving an organisations exposed API’s, how can we ensure, the Partner is requesting information on behalf of the human user (customer), and information is returned back that relates only to the human user (customer).

For instance, if the Partner’s Platform, was logged into by human user (customer) ‘A’, requiring to perform certain action ‘Aa’ on the Partner’s Platform. For this purpose, the Partner should be requesting the organisation hosting the API’s exposing the customer information, specifically for the human user (customer), who has logged into the Platform. In other words, the Partner system should be only asking for information related to human user (customer) ‘A’, the Partner system should not ask for information related to human user (customer) ‘B’.

How do we ensure, this restriction is applied to the Partner system using the M2M Pattern to invoke the organisation API’s, exposing information of the human user (customer). One of the thoughts that came to mind was, is it possible for the JWT access token to contain the human user (customer) identifier such as an “OnBehalfOfUser” identifier. This identifier could then be checked by the organization API, to ensure the “OnBehalfOfUser” in the JWT token, is the same as the “customer reference identifier” passed into the API, via the API URI path (or the API payload).

The key goal that I am seeking to achieve is to prevent an attacker from deriving the customer information simply by introspecting the API URI path (or the API payload) that may contain information of the “customer reference identifier”. For instance, if the API URI path is something like
“/identity/28207179” then, an attacker could introspect the API URI and attempt to invoke subsequent request such as “/identity/28207180” and “/identity/28207181”.

I am seeking to understand how the prevent the above attack with Auth0.

Also keen to understand Auth0 best practices, that can be leveraged for this purpose.

Please advise.