Implement built-in delegation/impersonation support (RFC8693)

[kevinchalet]

The OAuth 2.0 token exchange specification - originally known as "OAuth 2.0 Token Exchange: an STS for the REST of us" - was finally standardized last year.

Note: OpenIddict 3.0 already supports the requirements brought by this specification (like being able to set multiple audience or resource parameters, which was explicitly disallowed in the original OAuth 2.0 specification), as they were already part of ASOS 2.0 and OpenIddict 2.0.

RFC: https://tools.ietf.org/html/rfc8693

[ahanoff]

hi @kevinchalet, could you please explain how far this feature from completion and what is required to complete it? I most likely need this in my project soon, would be great if it supported out of the box in this awesome project

[a-a-k]

still no milestone?

[kevinchalet]

The work required to implement delegation support was supposed to be funded by a company but they changed their mind and opted for a different approach so it's no longer on top of the list.

[a-a-k]

@kevinchalet oh, I see. Could you tell, how much is it if our company decided to sponsor that, and what ETC would be then?

[mzros]

any news on this?

[kevinchalet]

@mzros nothing planned in the short term. That said, the demand is growing so I may consider implementing it at some point (maybe as a paid/sponsors-only feature?)

[codymullins]

@kevinchalet I'm adding this support to our local version, at least the delegated / composite token. If there's interest, I'm happy to PR this later on.

{
  "iss": "https://localhost:7243/",
  "exp": 1709912220,
  "iat": 1709908620,
  "jti": "bd5e0594-716e-43e2-b9e2-893970408a64",
  "sub": "01HRF356DTZ1WFNR980P05B228",
  "act": {
    "sub": "console"
  },
  "oi_prst": "console",
  "client_id": "console",
  "oi_tkn_id": "e303d0dd-1519-4acf-b3f0-9e459e76f780"
}

[kevinchalet]

@codymullins thanks for reaching out! A company offered to fund that: it's very recent and we're still discussing the details (e.g it's still unclear whether they want/need support in the client stack).

I'll let you know how it goes.

[jan-johansson-mr]

Although RFC 8693 is interesting, I'd argue it is not a good proposition if the exchange is with the identity server. Why? Because it makes the identity solution convoluted with something else than identity management - topology. If you think about it. The identity solution now have to know about call chain A -> B -> C ... -> D, and keep track on what B -> C mean, given the sub, audience, resource and so on. Why should the identity solution keep track on the topology for a solution? The topology of the solution is in the domain of the solution, not the identity. There are multiple ways of solving who may call who, rather than to put it in the identity domain. And when the topology of the domain changes? Then we have to go to the identity domain and update the knowledge of the topology there. It can easily become a nightmare.

And if you read more of RFC 8693, it allows multiple audiences, or resources, and any combination of, with either a required scope list or none, producing either a minimum of returned scopes or Cartesian product there of. It is complicated.

To be fair, the RFC 8693 says STS (security token service), and that can mean anything. If the authentication is tied up in a separate entity (STS), rather than the identity server (STS), then the proposal is fair. The proposition though, ties to the token endpoint that is found on the identity server. The people behind the Duende identity server split the responsibility of identity and authentication into separate entities.

Anyway, these are my thoughts, and of course, everyone is free to do whatever they want, and on top of that, take away the burden of developers to engineer something that do keep track of the topology and what chains are allowed and the conditions for that.

Thanks! 😄

[codymullins]

@jan-johansson-mr makes a solid point. I've waffled back and forth on this as well, and how much exactly should live in the identity server solution.