Refactor client authentication on OAuth2 endpoints into a login flow
Basics
Logistics
Basics
Logistics
Description
To support other use cases and more general support for other client authentication methods, we want to leverage the existing IdP login flow machinery to handle client authn to the token, introspection, revocation, etc. endpoints.
Right now this is all handled by a single action bean in those flows. The most strictly correct thing would be to turn each client method into its login flow, but this gets hairy because of the overlaps with existing uses of some of those methods and the complexity of configuring it. For now I'm envisioning a single OAuth2 login flow that reuses as much of the existing code as possible and handles all the different types internally, but with more generality.
Part of this includes turning the existing metadata-backed client secret verification into a new CredentialValidator type so that it can be used in series with other validators such as LDAP. We could also try and support mutual TLS by including our existing validation bean for that. JWT mechanisms would be handled with custom actions based on the current design.
This needs to remain 100% backward compatible so that the configuration will default appropriately.
JWT support added, pending completion of patch on old branch to be ported back up. Removed the now-unused action bean that used to handle endpoint auth.
Scott CantorDecember 21, 2021 at 7:50 PM
Initial work is done minus JWT validators, disabled two tests for now. Discovered that introspection and revocation flows don’t appear to actually allow for JWT methods right now anyway, waiting to port up work on that from the 3.0 branch once that’s done and tested.
Have not tested actually plugging in LDAP/etc. instead of the clientinfo option for the moment, but mechanically no reason it won’t work fine.
Other login flows would work in principle but that isn’t likely to be a need unless something unusual comes along. Building CredentialValidators is generally easier and this flow assumes that they can be based on things other than username/password when required.
To support other use cases and more general support for other client authentication methods, we want to leverage the existing IdP login flow machinery to handle client authn to the token, introspection, revocation, etc. endpoints.
Right now this is all handled by a single action bean in those flows. The most strictly correct thing would be to turn each client method into its login flow, but this gets hairy because of the overlaps with existing uses of some of those methods and the complexity of configuring it. For now I'm envisioning a single OAuth2 login flow that reuses as much of the existing code as possible and handles all the different types internally, but with more generality.
Part of this includes turning the existing metadata-backed client secret verification into a new CredentialValidator type so that it can be used in series with other validators such as LDAP. We could also try and support mutual TLS by including our existing validation bean for that. JWT mechanisms would be handled with custom actions based on the current design.
This needs to remain 100% backward compatible so that the configuration will default appropriately.