AEM 6.5 AMS/Local OAuth2.0 + Assets HTTP api not working, it works with basic auth

Hi ​@FrancoisCournoyer,

OAuth with AEM 6.5 AMS should work with the Assets HTTP API, so you are not limited to basic authentication. The error usually means the OAuth token is valid, but the service user linked to that token does not have the correct repository-level permissions or path mapping needed to create nodes under /content/dam.

1. The Bearer token is being generated correctly, so OAuth setup itself is working.
2. “Can't create child on a synthetic root” usually happens when AEM cannot properly resolve or write to the target DAM path.
3. Most often, this means the OAuth service user does not have full create/modify permissions on /content/dam/companies/product-staging.
4. Check that the ScopeWithPrivileges mapping includes:
   • Read access
   • Modify/Create node permissions
   • Replicate if needed
5. Also verify the folder path already exists in DAM before upload — Assets API may fail if parent folders are missing.
6. Confirm the OAuth client is correctly mapped to the intended service user, not just authenticated successfully.
7. Basic auth works because admin has unrestricted rights, while OAuth only gets scoped permissions.

In short: OAuth is supported, but the issue is likely permission mapping or folder path access for the OAuth service user, not the Assets API itself.

Thanks & Regards,

Vishal

Hi ​@FrancoisCournoyer 

I dug into the error and it’s not an issue in the Assets API itself; it’s a permissions / OAuth configuration issue.

• With Basic Auth as admin the same URL works, which proves the API and DAM path are OK.
• With OAuth, AEM executes the call as the user resolved from the access token (usually a technical account). That user currently does not have sufficient rights under /content/dam/companies/product-staging, and AEM throws Can't create child on a synthetic root.

To move forward, please:

1. Call a simple URL (like /.json) with your Bearer token and confirm which AEM user is being used.
2. In /useradmin, temporarily add that user to the same DAM author/administrator group that can upload assets today, then retry the /api/assets/... upload.
3. If that works, replace the broad group membership with explicit read/write ACLs on /content/dam, /content/dam/companies, and /content/dam/companies/product-staging for this technical account.
4. If you’re using a custom ScopeWithPrivileges, also double‑check that:
   • The scope name requested by the client matches your implementation, and
   • Your OAuth resource server/scope components are active and actually used (the default OAuth2ResourceServerImpl may need to be disabled or overridden).

Once the technical-account user has the correct DAM permissions, the Assets HTTP API will work over OAuth just like it does with Basic Auth.