Working group proposal: OIDC improvements

[sberyozkin]

Goal

The goal of this working group is to improve quarkus-oidc by:

• implementing important new security features
• continuing with improving the way OIDC requests can be intercepted
• prioritizing on some other open issues such as using JWT bearer client authentication to complete the authorization code flow
• engaging with the community and understanding what may have to be simplified to improve a user experience

Progress tracking

See the following GitHub issues:

• #33059 Create OIDC questionnaire
• #36250 OIDC Dynamic Client Registration
• #42115 Support for DPoP for quarkus-oidc
• #4482 Support for X509 certificate binding for quarkus-oidc
• #39185 Migrate OIDC extensions from ConfigGroup to ConfigMapping
• #42117 Add OIDC response fiters
• #40013 Support JWT bearer authentication to complete the code flow
• #41890 Return OIDC code flow error_code and error_description directly to the user in devmode

End in Sight

This work is done when users respond to the OIDC questionnaire and the simplifications tasks, if identified, are completed.
All other listed tasks must be completed as well.

[cescoffier]

Thanks @sberyozkin !

Can you tell us more about the "OIDC questionnaire", it's the first time I hear about it (or, I totally forget about ti, which is totally possible).

[sberyozkin]

Can you tell us more about the "OIDC questionnaire", it's the first time I hear about it (or, I totally forget about ti, which is totally possible).

I want to collect feedback from Quarkus OIDC practitioners, who use it in prod, as well as from users who may have tried it. I'd like to understand what their experience is or has been, what features they use or miss, or what they think will help to push it to the next level.

I'll work on preparing a list of questions at #33059 and then once the questions are ready I'll ask in all the channels, where I can, to support the questionnaire. I'm a bit vague about mechanisms to make it work, but I'll figure it out

[cescoffier]

Awesome! Thanks! I may have missed the ping on the issue.
I'm looking forward to seeing the results.

[sberyozkin]

@cescoffier @maxandersen, I'd like to open a survey next week, I'd appreciate if we can have an announcement in the Discussions, as not everyone is on X or quarkus-dev.

[sberyozkin]

Thanks @michalvavrik, sure, hope we can get some feedback if we keep it open for up to 1 month I guess.
By the way, Max, Clement, as suggested at #33059, if you'd like to propose more questions, please let me know. Anyone is welcome to propose more questions :-)

[michalvavrik]

Anyone is welcome to propose more questions :-)

I was thinking about it and I can't really find any question. The questions there covers required. It always depends on respondent how he approaches it. My only suggestion is to concentrate on Wildfly to Quarkus migration path. Get questions to customers (not only community) that use EAP with Elytron OIDC, ask them whether they experimented with Quarkus (did POCs) and what would make their migration smoother.

[sberyozkin]

@michalvavrik I have a question for users who had a Vert.x OIDC experience, I can copy and paste that one and ask the same question about EAP. I'd like to avoid asking very technical questions, for users to finish the whole survey, with all the time constraints for everyone :-)

[sberyozkin]

@michalvavrik Instead of creating one more question for WildFly Elytron, and then possibly for other systems like Spring, I've updated the existing Vertx OIDC only question to ask users if they have had an experience with Vertx OIDC or WildFly Elytron, or Spring, and if someone has some relevant experience, hopefully they will provide some feedback

[michalvavrik]

I see it, yes, that looks good.

[sberyozkin]

As far at the plan for the OIDC is concerned, apart from whatever we'll consider to look at following the survey results, elevation of the token security is a major theme right now.

I refer to the X509 token binding and DPoP.
We are literally 1 step away now from supporting the former option for FAPI applications, while the latter is poised to become the main tool for SPA applications, for ex, with Okta just publishing a blog entry about DPoP.

I'm going to prioritise on these 2 issues.