Token Exchange at a REST API Gateway to federate authentication while maintaining detailed authorization (think ABAC) within the API?

I'm on the verge of creating a service within our resource server that would exchange an externally generated access token for an internally generated access token. However, this feels wrong. I have not found evidence of anyone else needing this pattern, which is a good sign that I'm missing something. Details We are running a typical REST based SOA. We delegate authentication to Auth0 so that we can support customers with different Identity Providers. As is, we receive API requests and perform auth based on the access token generated by Auth0. However, we want to manage detailed API permissions internally and we want greater control over the token's life cycle (ie, forced server side revocation.) Auth0 does support custom claims, but that would require a very tight coupling between our server and theirs (or our rules in their server.) Also, that doesn't solve the forced revocation need either. It seems like this need can be met by exchanging the Auth0 generated access token for a new access token generated by our server, which could inject claims about the user/identity's configured permissions. This would allow us to control, well anything we want about the token, including revoking it. Concerns I keep scouring OIDC and OAuth2 specs, and searching for others with a similar need. The lack of any hits has me concerned. Is there a better way to manage authorization internally, while still delegating authentication to a provider like Auth0? Is there a better way to support token revocation than generating and tracking tokens oneself? Is it possible to maintain stateless tokens and support revocation at the same time? (If this is too much for one SE post, then ignore this part.) Update! I discovered Token Exchange which looks like what I'm looking for... an OIDC / OAuth2 based version of a Secure Token Service that can exchange tokens from one side of a federated heterogeneous environment for tokens managed by another side of the environment. So, I'll refine my question: Based on the use case I've described, is the Token Exchange model appropriate? If not, what?
http://dlvr.it/S1hrlw