February 2022 Update

The last month included a couple of patch releases, to the IdP and the OP plugin, the latter a security fix of which all deployers should take note. Work continues in parallel on the active work streams and we should be able to ship IdP V4.2 and the updated OP plugin this quarter as planned. We have begun to make adjustments to our POMs to prepare for the planned switch to using signed and verified third-party artifacts from Maven Central, and the new releases are expected to be the first ones using the new build process.

The IdP release is more or less just a patch but has a grab bag of small improvements. Updating to it should present no complications.

The OP update will include a more significant set of new features and capabilities, and we are working to finalize the “vision” for some of the new OAuth features to understand how they will impact our traditional deployment model. As the work has progressed it has become clear that our standard world view of “knowing” and registering (via metadata) all of the systems that interact with the IdP is incompatible with a full implementation of some of these features. With this initial support of the OAuth client_credentials grant type, we plan to begin the move towards a more open deployment model that focuses on knowing as much or as little as people prefer about the interacting systems.

While authentication via service accounts is still a requirement for clients of the OP’s token and introspection endpoints, this can potentially be delegated to an Identity Management system; metadata will be an optional choice for both clients and resource servers (token audiences), allowing deployers to lock down the system as much or as little as they prefer to support their use cases. When metadata exists, more control over fine-grained behavior becomes possible, but default behavior won’t require it, at the deployer’s discretion. With the model under consideration, either clients or resource servers can be independently locked down (or not) to require metadata as a group. It will also be possible to limit the resource servers (audiences) for which clients can request tokens, using an extension to metadata (or other another pluggable source of policy if preferred).

While this initial version will include full JWT support for this new grant support, we are not planning to open this up to all uses of access tokens in order to ship this sooner and get more experience before making changes to the existing features. We are also not planning to add support for full 3-legged (really 4-legged) OAuth yet, as this work is (even) more complex to retrofit into the existing code and will be easier to tackle after the 2-legged (really 3-legged) client_credentials support is more well-tested.