Delegation / Impersonation by trusted clients

[jshearer]

Is your feature request related to a problem? Please describe.

I am using Hydra to manage OAuth tokens for a set of microservices. I have come to the point where one service needs to request user-private information from another service in order to fulfill its request. In addition, the front-facing request is publicly accessible -- essentially, we are trying to expose a "projection" onto certain user data (as configured by the user) which requires accessing a config object served by a separate service that isn't publicly accessible. Before we split this into microservices, this wasn't an issue since we could just make a database request for the config and bypass the request-level authorization, but now we don't have that capability any more and need a more fine-grained way to do this.

Describe the solution you'd like

What I would love to do is be able to have the first service ask Hydra for a token whose subject is set to the owner of the data (and possibly some metadata on that token, a la ConsentRequestSession

Describe alternatives you've considered

It seems like this has been partially discussed before here but nothing came of it. I also found this page talking about almost exactly what I want to do (exchanging a user token for a new "delegated" token), except that I want to be able to do it without a user token in the first place (since the user already gave their consent).

Additional context

Do you have any suggestions for other ways to accomplish what I'm trying to do here? In our situation, we will always own all OAuth clients so I'm not worried about third party clients being able to abuse this feature, but I can understand that that might be a worry. One thing that the above article mentioned is a special grant type (delegation or impersonation), so maybe clients could just be restricted from making those kinds of token requests in the same way you can restrict a client from making other kinds of requests now (token, code, etc).

[aeneasr]

Thank you for opening this discussion. Unless this comes from a IETF peer-reviewed open standard, there is no way this will land in this project. Regarding JWT assertions, which might solve your use case, see #305 . There's someone working on SAML assertions iirc so if those are implemented we can also add JWT assertions quite easily. Keep in mind that they won't solve the consent step, only the authentication step.

I have too little context of your security, architecture, and threat model to make any recommendation. However, I wouldn't use OAuth2 for inter-service authorization. I'd also have a system that supports more than one credential type (eg oauth2 access tokens and mTLS and JWT bearer auth). I'd recommend giving oathkeeper a look which can help you with that.

[aeneasr]

Any questions? Otherwise I will close this as a nofix. Feel free to comment later in case you have additional questions