On-Behalf-Of token exchange with Per-Application Access

Get Help
,
1

I want to use on behalf of token exchange for a few of our endpoints, but I currently run into issues on organizations with Per-Application Access enabled.

The moment I turn it off, it works. But when I enable it, I get an ‘invalid request’ with as description ‘parameter organization is invalid: org_blablabla’ (with blablabla obviously replaced with the actual org id) on the /oauth/token endpoint.

I’m following this tutorial: On-Behalf-Of Token Exchange - Auth0 Docs
I’ve also tried adding the custom api client as one of the applications of the organization but this had no effect.

I know that Per-Application access is currently in early access, but we want to use this if possible.
And I was wondering if this is a known issue or whether I need to follow some other steps perhaps not described in the tutorial.

3

Hi @tvc

Welcome to the Auth0 Community!

I understand that you are looking to use On-Behalf-Of (OBO) token exchange, however you are having issues on organizations with Per-Application Access enabled.

Please allow us some time to investigate and we will return with additional details in a timely manner.

Thank you for your patience!
Gerald

4

Hi @tvc

Thank you for your patience!

The behaviour that you describe appears to be an interaction limitation within the current Early Access phase of the Per-Application Access feature when combined with the On-Behalf-Of (OBO) token exchange flow.

If you absolutely need to use OBO token exchange in your current architecture, you will need to keep Per-Application Access disabled for the affected organizations until this compatibility is fully resolved by the engineering team.

Official explanation and recommendation

Here is exactly what is happening under the hood and why your workaround didn’t take effect:

1. The Custom API Client is Treated as Machine-to-Machine

The error invalid_request: parameter organization is invalid: {org_id} is Auth0’s standard rejection when an Organization refuses an authorization request from a specific Client ID. When you enable Per-Application Access, the Organization strictly enforces its allowed applications list.

However, Per-Application Access in Early Access is primarily designed to validate user-facing applications (types eligible for use_for_member_access like SPA, Regular Web Apps, and Native). The OBO exchange relies on a Custom API Client acting as a Machine-to-Machine (M2M) client to swap the token. Because of how the /oauth/token endpoint currently evaluates Per-App Access rules during the exchange, adding the Custom API Client to the Organization’s applications tab manually fails to bypass the restriction.

2. Third-Party Application Strictness

It is also worth noting that this exact parameter organization is invalid error is the default response if the client making the request is classified as a “Third-Party Application” (or Partner App). By default, Organizations deny authentication requests from third-party apps unless an administrator explicitly enables third-party access for that Organization.

Key Takeaway / Recommended Action:
Because Per-Application Access is still in Early Access, edge cases involving advanced token delegation like OBO are expected. At this moment, the only viable workaround is to disable Per-Application Access on the Organizations where you need the OBO endpoints to function.

Thank you for pointing out this behaviour! Feel free to reach out to us for any other issues or requests, we will gladly look into it.

Have a great one,
Gerald

5

Hi Gerald,

Thanks for the quick reply!

I’ll disable this feature for now.

Is there btw. an eta for when this (and perhaps other) early access feature(s) are expected to leave early access?