Provide OIDC Mock DevService

[sberyozkin]

Description

Right now, when working with quarkus-oidc in devmode, Keycloak users can develop with DevServices for Keycloak where a Keycloak is launched, Dev UI will allow log in to Keycloak and use tokens created by real Keycloak server for testing Quarkus, or access Keycloak Admin Console for some more advanced realm setup, etc.

This is all great but the question is how to help non-Keycloak users work in devmode ? If for example, a user is working with Azure and has quarkus.oidc.auth-server-url already pointing to the Azure URL, then, in devmode, they can use the same DevUI for testing their application. But if no Azure account has been set up yet, then there is no way for this user to start developing a simple OIDC application without having to generate tokens manually.

In fact it is not quite true, Azure users can still use Dev Services for Keycloak to start developing without having to setup Azure account - this is because Keycloak will return a standard signed ID JWT token, etc. But it may feel unusual for such users.

Also it takes about 7 secs on a quite fast laptop to launch a Keycloak container - we can try to save a couple of more secs but it is unlikely we can get 3 secs or so start up time for KC when launching it with TestContainers.

So it can make sense to offer an option to launch an OIDC Mock DevService which will support typical OIDC interactions, it will be a devmode endpoint which will create correctly signed tokens, verify them, support the code flow, etc. We have all of that code in OIDC test support code, so it should be quite straightforward to implement. If it will be supported then non-KC users will be able to test without having to generate tokens manually. And when necessary, all users can get a very fast start up with OIDC mock server already ready.

CC @maxandersen (and thanks for the idea)

Implementation ideas

No response

[quarkus-bot[bot]]

/cc @pedroigor (oidc)

[spirostz]

Hi @sberyozkin, not sure if it fits your needs, but we are using <artifactId>quarkus-test-oidc-server</artifactId> with @QuarkusTestResource(OidcWiremockTestResource.class) which is a Wirework equivalent to keycloak. Of course the startup is instant since its not an actual "Test Container".

See: https://quarkus.io/guides/security-openid-connect#integration-testing-wiremock

[sberyozkin]

Hi @spirostz Thanks, right, the problem with using OidcWiremockTestResource as a generic DevService capability is that it may be difficult to fit it into the existing OIDC DevUI capabilities, for example the logout support for the code flow, so I've been thinking of copying some of the code from there to the oidc/deployment to support some straightforward Vert.x routes, but I'll see how it goes when I'll be having a closer took, thanks

[bulldog98]

Is it in scope to use this dev service for quarkus-oidc-client too?

[sberyozkin]

@bulldog98 Sorry I missed your question - for testing quarkus-oidc-client you can use the existing DevServices for Keycloak, the sharing feature, for example, you start the quarkus-oidc server application, then, separately, start the client application which uses quarkus-oidc-client

[FroMage]

I'm not sure if this is something that is solved by the new "lightweight" dev services, or by the OIDC known providers mock test resources of https://docs.quarkiverse.io/quarkus-renarde/dev/security.html#_testing_oidc_providers

[michalvavrik]

I'm not sure if this is something that is solved by the new "lightweight" dev services, or by the OIDC known providers mock test resources of https://docs.quarkiverse.io/quarkus-renarde/dev/security.html#_testing_oidc_providers

I just had a quick look at OIDC know providers mock test resources, because I didn't know about it - it looks promising, but the idea here was to do it as dev service for this way, you can also use it during development. you can't use test resources in dev mode, can you?

the new "lightweight" dev services

Can you point me to what you mean by this? class signature or github link will do. Thank you

[michalvavrik]

Ah, sorry, I can see https://github.com/quarkusio/quarkus/pull/35324 is linked to this now. thanks

[FroMage]

I just had a quick look at OIDC know providers mock test resources, because I didn't know about it - it looks promising, but the idea here was to do it as dev service for this way, you can also use it during development. you can't use test resources in dev mode, can you?

Well, the logic is the same as a dev service or as a test resource, but you're right they don't come in play at the same time.

My reasoning for writing these as test resources was that I wanted to make sure Quarkus didn't regress when supporting these providers (which has happened several times) because we didn't have a test suite to check them, and I didn't want the test suite to actually require contacting these providers, so I had to mock them.

And also, I felt that users would also want to make sure their tests would work with these providers, again, without contacting them during testing.

Now, as for requiring provider-specific dev services, I'm not entirely sure I see their use-case. Why would you need to have a dev service that returns different information to your application? All I need from an OIDC dev service is: "log me in and give me user info/roles/whatever". I'm not sure I would benefit from that dev service being different in case of Google/Apple/Keycloak. Am I missing a use-case?

Most times I will either need either:

• the new lightweight dev service to make sure I can log in without OIDC config
• the real Google/Apple/etc OIDC services, in dev mode, because I want to really make sure it works before I deploy it, and the UI is right, and manually calling them is very few calls, so unlike CI, it's acceptable.