Support for OIDC public-key property

[sberyozkin]

Fixes #5828

CC @cescoffier

[pedroigor]

Out of curiosity, what is the use case we are solving? Users that just want quarkus-oidc as a generic bearer JWT token authentication mechanism?

[sberyozkin]

Hi @pedroigor Awhile back we touched on it with Stian and @stuartwdouglas as well, and it was only to support some simple service cases or, to simplify the tests.
And Clement, @cescoffier, also asked for this option, as using a docker image is not possible for the tests in his case... @cescoffier, can you clarify please ?
These changes do not affect at all the current code except that I had to extract some common code into the functions. Note a visible info log message is logged once. But I'm not 100% sure this PR will need to be backported.
Thinking more about it, the case where no OIDC server is involved can be well covered by quarkus-smallrye-jwt. @cescoffier, can that be an option ? This PR is a bit of a hack :-), though as I said the existing OIDC-aware code is not affected
Thanks

[pedroigor]

Yeah, that is what I thought too so that smallrye-jwt could be an option to address the same use case (pure JWT bearer token authentication).

In any case, if you still think this one should go in. I'm OK with it too.

[sberyozkin]

Hi @pedroigor thanks, I was wondering that may be it can be handy to, while already working with quarkus-oidc with the service application, have an option to quickly add public-key for testing the flow only excluding the OIDC connection. Something like that.
What I'm finding good that we'll actually do something about public-key :-), if this PR were found to be problematic then we'd just remove this property :-)
Thanks for the approval, I'll keep the PR open for a bit longer.

[cescoffier]

My use case is very simple, and I'm pretty sure many will have the same case.
I have a REST endpoint, protected using OICD. In "prod" I use keycloak, no problem with this. Now I'm in dev or in test mode, I don't necessarily want to start keycloak, configuring the realms and so on. Today it can be very hard to check my API with openapi (because I don't have access to the token) or in my tests.

Of course, I can use the fake users/groups in dev and test - but that introduces quite some difference with the final behavior and it's a packaging dilemma (this unsafe extension is going to be in the classpath of the application).

The OIDC extension defines this public key attribute, and it would make sense to honor it. It would enable:

• using Swagger / OpenAPI in dev mode
• allowing tests to be blasting fast

Note: I use Jwtonizer to generate the token and the public key.

[sberyozkin]

@cescoffier Thanks, IMHO it is reasonable to have it supported then as switching to the alternative with quarkus-smallrye-jwt won't make sense in such situations.
@pedroigor has already approved, @stuartwdouglas can you please review ?

[gastaldi]

LGTM

[gastaldi]

@sberyozkin should this PR be backported to 1.3.0.Final?

[sberyozkin]

Hi @gastaldi, thanks for the approval. I'd be inclined to keep it to 1.4.0 as even though the existing OIDC code has not been changed, it has been moved around. @cescoffier, are you OK with it or would really prefer to have in 1.3.0 ?
Thanks

[cescoffier]

I let @gsmet decides. It's really a developer experience feature (testing your app).

[sberyozkin]

@cescoffier, ok thanks, I'll merge to the master for now

[sberyozkin]

This is nearly funny, I press on a green Merge pull request button and it does not work, I've logged out of GitHub and in again. Can someone merge please ?

[gastaldi]

Green merge button 1x0 @sberyozkin 😄

[sberyozkin]

@gsmet, hi. I think something is wrong with my permissions, I can't even add a backport label for you to review it a backport candidate

[sberyozkin]

@gsmet looks like I can do something here again :-). So I've added a backport label. It would be good if @stuartwdouglas could also have a quick look but it may be too late by then...

[gsmet]

I don't understand. You say you don't want to backport it and then you add a backport label?

[sberyozkin]

@gsmet I thought having a label was a pre-requisite to be even considered for a backport. Indeed I had the reservations because I moved the code around (encapsulated it inside the functions so that it can be reused between the OIDC and no OIDC flows and even though it looks Ok on the eye it has not been stressed yet. Clement suggested that we should leave it to you to decide, hence I thought I should have the label. Sorry for a confusion if any.

[gsmet]

I think it's a bit too late for that kind of change.

Let's leave it for 1.4 and if someone complains, we can consider backport it at some point.

[StuartDouglas]

Hi folks I think you have the wrong email address for your Stuart Douglas, so if you could drop me from this chat, I'd be obliged:) Best (Another) Stuart Douglas

…

On Thu, 12 Mar 2020 at 21:24, sberyozkin ***@***.***> wrote: @gsmet <https://github.com/gsmet> I thought having a label was a pre-requisite to be even considered for a backport. Indeed I had the reservations because I moved the code around (encapsulated it inside the functions so that it can be reused between the OIDC and no OIDC flows and even though it looks Ok on the eye it has not been stressed yet. Clement suggested that we should leave it to you to decide, hence I thought I should have the label. Sorry for a confusion if any. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7750 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACEYFKKDD777C3XGKNUFTE3RHFHITANCNFSM4LFGECXA> .

-- *Obverse Bookswww.obversebooks.co.uk <http://www.obversebooks.co.uk>BLACK ARCHIVE: THE SILURIANS* *SILVER ARCHIVE: STRANGER THINGS*

[gsmet]

@StuartDouglas sorry, I think you probably have been mentioned at some point by mistake. That was apparently fixed as I don't find any mention of you now but GH still sends you the email so you should probably unsusbcribe yourself from the notifications (bottom of the left panel). Sorry about that!

[sberyozkin]

@gsmet, thanks and also another thanks for fixing the id of our Stuart @stuartwdouglas :-)
I had this bizarre situation yesterday when I could comment and then could not edit, I actually saw that error, GitHub actually 'fixed' stuartwdouglas to StuartDouglas, and then I could not fix it; had to update the browser and then forgot to fix.