Support multiple OpaqueTokenIntrospector about spring-security HOT 6 OPEN

Additional context: We need an OpaqueTokenIntrospector that iterates over multiple OpaqueTokenIntrospector and returns the first successful result.

from spring-security.

Hi @CrazyParanoid, thanks for the suggestion.

There are cases where support for multiple OpaqueTokenIntrospectors in an OpaqueTokenAuthenticationProvider is needed. This is easier than adding another provider to ProviderManager, because OpaqueTokenAuthenticationConverter is often the same for different cases.

It is unclear to me whether the delegating implementation is truly needed, because there are likely other cases where both the OpaqueTokenIntrospector and OpaqueTokenAuthenticationConverter need to be customized and as you implied this is already supported. I feel that the need would be clearer if the framework itself had use for a delegating implementation, but it does not.

Additional context: We need an OpaqueTokenIntrospector that iterates over multiple OpaqueTokenIntrospector and returns the first successful result.

It seems that the contract for OpaqueTokenIntrospector does not explicitly allow for null return values. I think it would be better to leave this to the consuming application to provide.

Having said that, I think we can leave this issue open for a while and see if anyone else has a need for it before proceeding, at which time we can evaluate options.

from spring-security.

Hi @sjohnr thanks for your feedback!

It is unclear to me whether the delegating implementation is truly needed, because there are likely other cases where both the OpaqueTokenIntrospector and OpaqueTokenAuthenticationConverter need to be customized and as you implied this is already supported.

At the same time, there are many cases where the result of introspection is the same, especially if the identity provider does not strongly contradict the specification. I could be wrong, but setting up an OpaqueTokenIntrospector seems like a simpler solution in such cases.
I look at the JwtAuthenticationProvider and I see that the framework allows me to customize it for almost any use case without having to add a new JwtAuthenticationProvider to the ProviderManager. Is it possible to do the same for OpaqueTokenAuthenticationProvider? For me the answer is quite clear.

from spring-security.

Thanks @CrazyParanoid.

At the same time, there are many cases where the result of introspection is the same, especially if the identity provider does not strongly contradict the specification. I could be wrong, but setting up an OpaqueTokenIntrospector seems like a simpler solution in such cases.

My concern is providing too many ways to do the same thing. Spring Security has often received feedback that there many ways to do the same thing, and that it's confusing. If there's already a way to do something, providing a more convenient way is not necessarily best option in all cases. Make sense?

I look at the JwtAuthenticationProvider and I see that the framework allows me to customize it for almost any use case without having to add a new JwtAuthenticationProvider to the ProviderManager.

I agree that adding an authentication provider is a more advanced option. Can you clarify, is it possible to configure Spring Security for your use case (if slightly inconvenient)? Or is it not possible?

from spring-security.

Spring Security has often received feedback that there many ways to do the same thing, and that it's confusing.

It always seemed to me that this is a big plus of the framework. The more flexibility and the ability to customize everything, the more opportunities for developers to find the best solution for their case.

Can you clarify, is it possible to configure Spring Security for your use case (if slightly inconvenient)?

Yes it is possible, at the moment I am adding another OpaqueTokenAuthenticationProvider to the configuration.

from spring-security.

Thanks @CrazyParanoid. I am not necessarily in favor of introducing a class like this for the sake of convenience only, when it's not clear whether it will be useful to many users. I think my preference at this point would be to leave this issue open and see if other users have feedback on whether this is needed by upvoting the issue.

from spring-security.