Injected JsonWebToken Is Null When Using Both OIDC and JWT Authentication Mechanisms in Quarkus

[S0PEX]

I'm working on a Quarkus 3.24 application that supports two types of authentication:

1. Users authenticated via OIDC (Keycloak), using the standard authorization code flow.
2. Clients (agents or devices) authenticated via self-issued short-lived JWTs created at login time.

After reviewing the Quarkus documentation on supporting multiple HTTP authentication mechanisms, I implemented a custom HttpAuthenticationMechanism to choose between OIDC and JWT based on a custom request header (HELIX-AGENT).

However, accessing the JWT is not working as expected and results in inconsistent behavior: injecting JsonWebToken directly in a resource results in a NullJsonWebToken, whereas injecting SecurityIdentity and accessing its .principal property correctly returns a DefaultJwtCallerPrincipal containing the expected claims from the self-issued JWT.

Custom Mechanism Implementation

@Alternative
@Priority(1)
@ApplicationScoped
class CustomAwareJWTAuthMechanism @Inject constructor(
    private val jwt: JWTAuthMechanism,
    private val oidc: OidcAuthenticationMechanism
) : HttpAuthenticationMechanism {

    companion object {
        private const val HELIX_AGENT_HEADER = "HELIX-AGENT"
    }

    override fun authenticate(
        context: RoutingContext,
        identityProviderManager: IdentityProviderManager
    ): Uni<SecurityIdentity> {
        return selectMechanism(context).authenticate(context, identityProviderManager)
    }

    override fun getChallenge(context: RoutingContext): Uni<ChallengeData> {
        return selectMechanism(context).getChallenge(context)
    }

    override fun getCredentialTypes(): MutableSet<Class<out AuthenticationRequest?>?> {
        return mutableSetOf<Class<out AuthenticationRequest?>>().apply {
            addAll(jwt.credentialTypes)
            addAll(oidc.credentialTypes)
        }
    }

    override fun getCredentialTransport(context: RoutingContext): Uni<HttpCredentialTransport> {
        return selectMechanism(context).getCredentialTransport(context)
    }

    private fun selectMechanism(context: RoutingContext): HttpAuthenticationMechanism {
        return if (context.request().getHeader(HELIX_AGENT_HEADER) != null) jwt else oidc
    }
}

Problem

After a client logs in, it receives a JWT like this:

@POST
@Path("/logon")
@PermitAll
fun logon(@Valid dto: LogonWorkerRequestDto): WorkerLogonResponseDto {
    val worker = workerService.create(dto)
    val token = Jwt
        .subject(worker.id.toString())
        .preferredUserName(worker.name)
        .groups("worker")
        .sign()
        ?: throw IllegalStateException("Failed to create token")
    return WorkerLogonResponseDto(token)
}

The client then includes this token in future requests to the API, along with the HELIX-AGENT header to indicate that it is a client and not a user.

Although the JWT authentication mechanism is selected based on the header, OIDC still appears to be invoked and attempts to parse or introspect the JWT, leading to warnings such as the following:

OidcJsonWebTokenProducer - Identity is not associated with an access token.
Inject either 'SecurityIdentity' or 'UserInfo' if you need both code and bearer token flows.

Additionally, injecting JsonWebToken into a resource results in a NullJsonWebToken, even though injecting SecurityIdentity and accessing its .principal property reveals a DefaultJwtCallerPrincipal containing all the expected data from the self-issued JWT.

@Path("/secure")
class HelloResource @Inject constructor(
    private val identity: SecurityIdentity,
    private val jwt: JsonWebToken,
) {

    @GET
    @Authenticated
    fun getAuthenticatedUser(): String {
        return "Authenticated user: ${identity.principal.name}, JWT subject: ${jwt.name}"
    }
}

GET /secure

Authenticated user: Bruno12311, JWT subject: null

Questions

1. Why is OIDC still attempting to handle the request even when the custom mechanism chooses the JWT mechanism?
2. Is this expected behavior when using multiple authentication mechanisms in Quarkus?
3. How can I ensure that self-issued JWTs are handled only by the SmallRye JWT mechanism, and that OIDC is not invoked at all in those cases?
4. Why is JsonWebToken injection resulting in a NullJsonWebToken, even though SecurityIdentity.principal contains a valid DefaultJwtCallerPrincipal with all expected claims?
5. What would be the best to perform consistent authentication, i.e., retrieve a uniform user entity when multiple mechanisms are used?

Best regards,
Artur

[quarkus-bot[bot]]

/cc @geoand (kotlin), @pedroigor (oidc), @sberyozkin (jwt,oidc)

[michalvavrik]

@Alternative
@Priority(1)

Is what is supposed to do the trick, not the priority. I need to check what is going on there before I comment any further. Of course using the priority instead of the CDI annotations will work as well. In case the annotations stopped work for some reason, we need to check why and update the docs. Regardless, this needs to check, hopefully I'll be able to reproduce it.

[michalvavrik]

Let's wait, we need to run something before we make any conclusions. As for:

I think a similar issue was reported before

I never believed that it is a good idea to combine SR JWT and OIDC mechanisms together, but you were sure it works so I trust you.

[sberyozkin]

@michalvavrik, it is not about specific mechanisms as such though

[michalvavrik]

@michalvavrik, it is not about specific mechanisms as such though

true, I don't remember what I meant yesterday

[sberyozkin]

Np, I was actually thinking about the actual combination yesterday, I think the same usecase in the description can be supported with the OIDC multitenancy, where a self-issued token is verified with a tenant with configured public local key, this is the option that allows OIDC tenant to be totally local

[pauldpearson]

I too was having a ton of issues using both extensions and getting the NullJsonWebToken as well as:

2025-11-07 12:27:03,464 WARN [OidcJsonWebTokenProducer] (vert.x-eventloop-thread-4) Identity is not associated with an access token. Access 'JsonWebToken' with '@IdToken' qualifier if ID token is required and 'JsonWebToken' without this qualifier when JWT access token is required. Inject either 'io.quarkus.security.identity.SecurityIdentity' or 'io.quarkus.oidc.UserInfo' if you need to have the same endpoint code working for both authorization code and bearer token authentication flows.

So I ended up simply grabbing the token off the request:

@HeaderParam(value = "Authorization") String authHeader

and then parsing that with JWTParser

[sberyozkin]

@pauldpearson Sorry, I replied to @S0PEX's question, perhaps you have a different setup. See if customizing the priority helps, and also provide more details re your setup

[pauldpearson]

@sberyozkin Not a problem! Let me try that and see where it gets me thanks.

[michalvavrik]

OIDC still appears to be invoked and attempts to parse or introspect the JWT, leading to warnings such as the following

Just to be clear, this does not mean that OIDC is handling requests, I hope you have other reasons to believe that (like you enabled logging for io.quarkus.oidc log category). The OidcJsonWebTokenProducer is invoked because you are injecting JsonWebToken, that is all.

Would you mind putting together some reproducer? Just so that I don't have to guess what is your actual setup, because this doesn't really provide all the information and if there is actually a bug (or docs issue), I'd like to fix it.