Basic auth via OIDC

[Traivor]

Description

It doesn't appear the OIDC extension supports Basic auth. This is supported by the Keycloak adapter and the generic OIDC adapter which is now in Wildfly.

My use case is that for testing it is way easier to type in a user/pass into swagger/Postman/whatever than constantly grabbing new tokens separately.

Implementation ideas

No response

[quarkus-bot[bot]]

/cc @pedroigor, @sberyozkin

[Traivor]

I've tried combining with the elytron-security-properties-file extension and embedded users, but it seems to completely take over auth. I.e. any un-authed request gets a Basic challenge rather than redirecting to Keycloak.

[Traivor]

I should clarify that my app provides both REST endpoints and normal UI, so I need OIDC to do redirects on normal browser access while allowing Basic.

[sberyozkin]

@Traivor Hi, quarkus-oidc is not going to deal with Basic Authentication, quarkus-oidc is about dealing with tokens, so making it a conduit for forwarding basic credentials to Keycloak seems wrong to me. But indeed you can combine OIDC with other mechanisms.

When no credentials are provided and basic and OIDC mechanisms are enabled, Basic one takes priority. It may seem wrong for your case but we have users for whom it seems wrong the other way around.

You can customize it a few ways:

• Using path-based authentication - IMHO it is the best option, https://quarkus.io/guides/security#path-specific-authentication-mechanism
• Create a simple custom mechanism, https://quarkus.io/guides/security-customization#httpauthenticationmechanism-customization, have both BasicAuthenticationMechanism and OidcAuthenticationMechanism injected and delegate to the latter when the challenge is required and no Authorization header with Basic or Bearer schemes is available
• A possible variation of the 2nd option - have only a single custom mechanism which will always delegate to the injected OidcAuthenticationMechanism but which will have a priority higher than the one used by BasicAuthenticationMechanism

HTH, thanks

I'm going to close this issue

[sberyozkin]

@Traivor Also, I'd recommend https://quarkus.io/guides/security-openid-connect-dev-services, instead of testing manually

It will take care of getting the tokens for you and you can have Swagger UI seamlessly integrated into it

[Traivor]

The first two options look plausible. Thanks!

The third...before I read through the whole page, do you know if it is possible to adapt this to production? I provide the swagger ui as an end user service.

[sberyozkin]

@Traivor Unfortunately DevServices are only available at dev-mode time. But the first 2 options can be used in the production for sure

[Traivor]

Ah. Seeing reference to using an already running OIDC provider got my hopes up. Bummer.

I'll bend one of the other options to my will. Thanks for the help!

[sberyozkin]

@Traivor Np at all; We can try to optimize/improve further how multiple auth mechanims are combined - but IMHO it is the right approach for such cases

Cheers

[sberyozkin]

Ping us please with new issues if you see some options for improving the way the mechanisms are combined