Enhance OAuth2TokenExchangeAuthenticationProvider to support additional trusted issuers

[joshuawhite929]

Expected Behavior
OAuth2TokenExchangeAuthenticationProvider should be enhanced to support subject/actor tokens from other trusted issuers

Current Behavior
Today, OAuth2TokenExchangeAuthenticationProvider validates/authorizes the subject/actor token by looking for the JWT in the configured OAuth2AuthorizationService. Additional trusted issuers are not supported in the current implementation.

Context
The current OAuth2TokenExchangeAuthenticationProvider constrains token exchange process to a single IDP. I believe the spirit of RFC 8693 is to also enable token exchange across security domains.

If this is something that the team is willing to support, I have a working example of how OAuth2TokenExchangeAuthenticationProvider could be modified to support this need.

CC: @sjohnr , @jgrandja

[sjohnr]

@joshuawhite929

The current OAuth2TokenExchangeAuthenticationProvider constrains token exchange process to a single IDP. I believe the spirit of RFC 8693 is to also enable token exchange across security domains.

Can you please say more about why you feel the current provider constrains token exchange? Have you explored adding additional parameters to the request? What would be needed that isn't currently possible to support multiple IdPs?

[sjohnr]

Apologies @joshuawhite929 if my above response is confusing, I was thinking about this from the Spring Security (client) side. Please feel free to share any supporting information or an example you are thinking about for supporting multiple IdPs on the server side. However, please consider that the initial implementation was intentionally limited to a single IdP so we could have more conversation prior to targeting more advanced features such as this one.

[joshuawhite929]

I am definitely interested in the server side piece of this. I am currently on vacation and will be back with more detailed comments on Friday.

[joshuawhite929]

My companies OSS process is taking longer than I anticipated. Would you prefer to wait or close this issue and have me open another when ready?

[sjohnr]

Hi @joshuawhite929.

Would you prefer to wait or close this issue and have me open another when ready?

That depends I suppose. You wouldn't need to provide anything specific to your internal environment, I am just looking for some details on a use case at a high (e.g. abstract) level. In the opening comment you mention:

Additional trusted issuers are not supported in the current implementation.

If you can add more clarity around the details of what you're requesting here (a specific use case), that would be helpful since I'm not sure I have enough information from that statement to determine what enhancement would be targeted by this issue. If you feel you're unable to provide additional details at the moment, then I think we should close this ticket for now as I feel it is not actionable. Does that make sense?

[joshuawhite929]

I am looking to use a JWT as a authorization grant to obtain an access token from a different authorization server.

Today, the Spring Authorization Server assumes that the JWT specified by the subject_token/actor_token originates from itself. To facilitate a cross-domain token exchange, I am hoping to validate/trust a JWT from a different issuer. Does this make sense?

I believe this is briefly mentioned in the spec:

Whereas, urn:ietf:params:oauth:token-type:jwt is to indicate specifically that a JWT is being requested or sent (perhaps in a cross-domain use case where the JWT is used as an authorization grant to obtain an access token from a different authorization server as is facilitated by [RFC7523]).

[sjohnr]

I believe this is briefly mentioned in the spec

It is hinted at in the spec as you mentioned there, but it unfortunately does not spell out any details for how such a use case would work. I think that the spec is both broad and narrow, broad in the sense that many combinations of request parameters are technically valid, but narrow in the sense that very few such combinations have clearly defined behavior. Beyond the basic use cases supported by the initial implementation, we quickly run out of clear usage patterns.

My interpretation of the spec is that these other use cases could be defined by a specific implementation of a purpose-built security token service (STS) that clearly documents the use case(s) it intends to solve, what requests or parameter combinations are valid, what out-of-band setup is required to use them, etc. The use case you mention:

To facilitate a cross-domain token exchange,

...is still very general and while it might make sense, we would need a more specific use case to determine whether it makes sense for the framework to support it. I think there are still a variety of use cases that could be possible based on the broad definitions found in the spec. So focusing on what you have provided for the moment:

I am hoping to validate/trust a JWT from a different issuer

Simply validating an input token is not quite enough. There are certain outputs that we expect from this process. Currently, we can obtain all the information needed from the OAuth2AuthorizationService, which is why we only support internal tokens currently. To support an external token such as a JWT issued by another authorization server, we would need to define a contract that outputs all of the necessary details.

Some details are just used for additional validation, so they could be kept internal to the implementation. Beyond that, we need to know what "principal" (or end user) is represented by the combination of a subject token and an optional actor token. This whole process would end up being fairly generic and would probably look a lot like the existing OAuth2TokenExchangeAuthenticationProvider which provides the current implementation, except that it would use a JwtDecoder (from Spring Security) to perform the validation and extract claims.

If we do all of that, we still wouldn't have enough information to interpret the various allowed combinations of parameters in the request. For example, what if we want to support two issuers? What about a multi-tenant setup? Do we support combinations of internal subjects and external actors or vice versa? And what policies or validation are needed in each case? All of this would need to be accounted for, and would likely result in a fairly complex setup.

For now, I think just referencing the docs for how to implement an extension grant type and plugging in a custom AuthenticationProvider (see OAuth2TokenExchangeAuthenticationProvider) is a good place to start. If there's some learning you can take away from that, you can report back and perhaps we can discuss a more concrete use case.

What do you think?

[joshuawhite929]

I will look into this and get back to you

[joshuawhite929]

IMHO - 95% of the existing code/tests can be reused. I'm thinking that the only difference would be the "strategy" used to validate/authenticate the subject and actor tokens.

If we prefer to have this implemented in a different AuthenticationProvider class, can we consider pushing 95% of the code into an perhaps use a template method to validate/authenticate the subject and actor tokens?

Thoughts on this approach?