It might make sense to use multiple authorization servers here. This will allow you to provide the correct policies and scopes for the different use cases, without the two mixing. This means that the issuer of the token will be different.
3rd party web app would use their authorization server.
Your UI would use your authorization server.
The middleware would be issuer aware, not audience aware. My general feeling on why this matches your use case comes down to an issue that you will run into, which scopes are for which audience? If there is an overlap between your use cases (which I believe will be true because this sounds like b2b2c) I think haven’t issuer division, policy division, and scope division will be important.
Also, there may be some scopes for your UI usecase that may not require user consent for scope, but you need to enforce that for the 3rd party web-app. The issuer and scope division will be able to handle that as well.
Let me know if this sounds off, you have the complete information here