- I also decided to implement the OAuth2 Resource Server role, following Alessio’s response. This is working as well. However, after grepping through the codebase, I found the JWT Headers community module, which I believe has significant functional overlap with the OAuth2 Resource Server role. I assume only one should persist in the long term. I suspect the new Spring implementation involves less code and may be more reliable given its origin (I don’t intend to offend anyone, just I guess). However, if JWT Headers is also used in GeoNetwork, that could be a factor. It might be easier to decide which to keep once the migration is complete and we can compare the final features and codebase. I hope to finish everything within the remaining time. What does the community think?
Hi, Andreas, The JWT Headers is shared with GeoNetwork and is designed for single signon among multiple applications. It is also designed to be compatible with the Apache OIDC plugin (see docs). It also handles attaching tokens (for robot access). I haven't looked at the OAuth2 Resource Server, so I cannot comment on the overlap or if it does all of this. The JWT Headers code is very simple and doesn't really have any dependencies (at least structurally). Dave
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
