Quarkus 3.10 fails to start if some OIDC providers don't support UserInfo

[markusdlugi]

Opening this as discussion since I don't know if this can actually be considered to be a bug. Just wanted to discuss this and raise awareness about the behavior 😄

With #39428 some behavior was introduced to automagically detect whether UserInfo is injected in the application or not. If that is the case, the user-info-required property will be enabled by Quarkus itself.

While this is a nice QOL improvement for most Quarkus users, this can cause trouble when there are multiple OIDC providers configured and some of them don't support UserInfo acquisition. For example, we have a corporate OIDC provider that is used for user auth and additionally use an AWS EKS OIDC provider for M2M use-cases. The latter one does not have a user-info endpoint.

In such a scenario, Quarkus will fail to start with the following exception:

UserInfo is required but the OpenID Provider UserInfo endpoint is not configured. Use 'quarkus.oidc.user-info-path' if the discovery is disabled.
 java.lang.RuntimeException: Failed to start quarkus
     at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
     at io.quarkus.runtime.Application.start(Application.java:101)
     at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:111)
     at io.quarkus.runtime.Quarkus.run(Quarkus.java:71)
     at io.quarkus.runtime.Quarkus.run(Quarkus.java:44)
     at io.quarkus.runtime.Quarkus.run(Quarkus.java:124)
     at io.quarkus.runner.GeneratedMain.main(Unknown Source)
     at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
     at java.base/java.lang.reflect.Method.invoke(Method.java:580)
     at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:62)
     at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:33)
 Caused by: io.smallrye.mutiny.CompositeException: Multiple exceptions caught:
     [Exception 0] io.quarkus.runtime.configuration.ConfigurationException: UserInfo is required but the OpenID Provider UserInfo endpoint is not configured. Use 'quarkus.oidc.user-info-path' if the discovery is disabled.
     [Exception 1] io.quarkus.oidc.OIDCException
     at io.smallrye.mutiny.operators.uni.UniOnFailureFlatMap$UniOnFailureFlatMapProcessor.performInnerSubscription(UniOnFailureFlatMap.java:94)
     at io.smallrye.mutiny.operators.uni.UniOnFailureFlatMap$UniOnFailureFlatMapProcessor.dispatch(UniOnFailureFlatMap.java:83)
     at io.smallrye.mutiny.operators.uni.UniOnFailureFlatMap$UniOnFailureFlatMapProcessor.onFailure(UniOnFailureFlatMap.java:60)
     at io.smallrye.mutiny.operators.uni.UniOperatorProcessor.onFailure(UniOperatorProcessor.java:55)
     at io.smallrye.mutiny.operators.uni.UniOperatorProcessor.onFailure(UniOperatorProcessor.java:55)
     at io.smallrye.mutiny.operators.uni.UniOnItemOrFailureFlatMap$UniOnItemOrFailureFlatMapProcessor.onFailure(UniOnItemOrFailureFlatMap.java:67)
     at io.smallrye.mutiny.operators.uni.builders.UniCreateFromKnownFailure$KnownFailureSubscription.forward(UniCreateFromKnownFailure.java:38)
     at io.smallrye.mutiny.operators.uni.builders.UniCreateFromKnownFailure.subscribe(UniCreateFromKnownFailure.java:23)
     at io.smallrye.mutiny.operators.AbstractUni.subscribe(AbstractUni.java:36)
     at io.smallrye.mutiny.operators.uni.UniOnItemOrFailureFlatMap$UniOnItemOrFailureFlatMapProcessor.performInnerSubscription(UniOnItemOrFailureFlatMap.java:99)
     at io.smallrye.mutiny.operators.uni.UniOnItemOrFailureFlatMap$UniOnItemOrFailureFlatMapProcessor.onItem(UniOnItemOrFailureFlatMap.java:54)
     at io.smallrye.mutiny.operators.uni.UniOnItemTransform$UniOnItemTransformProcessor.onItem(UniOnItemTransform.java:43)
     at io.smallrye.mutiny.operators.uni.UniOperatorProcessor.onItem(UniOperatorProcessor.java:47)
     at io.smallrye.mutiny.operators.uni.builders.UniCreateFromPublisher$PublisherSubscriber.onNext(UniCreateFromPublisher.java:70)
     at io.smallrye.mutiny.subscription.MultiSubscriberAdapter.onItem(MultiSubscriberAdapter.java:27)
     at io.smallrye.mutiny.subscription.MultiSubscriber.onNext(MultiSubscriber.java:61)
     at io.smallrye.mutiny.subscription.SerializedSubscriber.onItem(SerializedSubscriber.java:74)
     at io.smallrye.mutiny.operators.multi.MultiRetryWhenOp$RetryWhenOperator.onItem(MultiRetryWhenOp.java:111)
     at io.smallrye.mutiny.subscription.MultiSubscriber.onNext(MultiSubscriber.java:61)
     at io.smallrye.mutiny.converters.uni.UniToMultiPublisher$UniToMultiSubscription.onItem(UniToMultiPublisher.java:94)
     at io.smallrye.mutiny.operators.uni.UniOnItemTransform$UniOnItemTransformProcessor.onItem(UniOnItemTransform.java:43)
     at io.smallrye.mutiny.vertx.AsyncResultUni.lambda$subscribe$1(AsyncResultUni.java:35)
     at io.smallrye.mutiny.vertx.DelegatingHandler.handle(DelegatingHandler.java:25)
     at io.vertx.ext.web.client.impl.HttpContext.handleDispatchResponse(HttpContext.java:397)
     at io.vertx.ext.web.client.impl.HttpContext.execute(HttpContext.java:384)
     at io.vertx.ext.web.client.impl.HttpContext.next(HttpContext.java:362)
     at io.vertx.ext.web.client.impl.HttpContext.fire(HttpContext.java:329)
     at io.vertx.ext.web.client.impl.HttpContext.dispatchResponse(HttpContext.java:291)
     at io.vertx.ext.web.client.impl.HttpContext.lambda$null$7(HttpContext.java:507)
     at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:279)
     at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:261)
     at io.vertx.core.impl.ContextInternal.lambda$runOnContext$0(ContextInternal.java:59)
     at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
     at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
     at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
     at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:566)
     at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
     at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
     at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
     at java.base/java.lang.Thread.run(Thread.java:1583)
     Suppressed: io.quarkus.oidc.OIDCException
         at io.quarkus.oidc.runtime.OidcRecorder$5.apply(OidcRecorder.java:159)
         at io.quarkus.oidc.runtime.OidcRecorder$5.apply(OidcRecorder.java:141)
         at io.smallrye.context.impl.wrappers.SlowContextualFunction.apply(SlowContextualFunction.java:21)
         at io.smallrye.mutiny.groups.UniOnFailure.lambda$recoverWithItem$8(UniOnFailure.java:190)
         at io.smallrye.mutiny.operators.uni.UniOnFailureFlatMap$UniOnFailureFlatMapProcessor.performInnerSubscription(UniOnFailureFlatMap.java:92)
         ... 39 more
     Caused by: io.quarkus.runtime.configuration.ConfigurationException: UserInfo is required but the OpenID Provider UserInfo endpoint is not configured. Use 'quarkus.oidc.user-info-path' if the discovery is disabled.
         at io.quarkus.oidc.runtime.OidcRecorder$11.apply(OidcRecorder.java:545)
         at io.quarkus.oidc.runtime.OidcRecorder$11.apply(OidcRecorder.java:519)
         at io.smallrye.context.impl.wrappers.SlowContextualBiFunction.apply(SlowContextualBiFunction.java:21)
         at io.smallrye.mutiny.operators.uni.UniOnItemOrFailureFlatMap$UniOnItemOrFailureFlatMapProcessor.performInnerSubscription(UniOnItemOrFailureFlatMap.java:86)
         ... 30 more
 Caused by: [CIRCULAR REFERENCE: io.quarkus.runtime.configuration.ConfigurationException: UserInfo is required but the OpenID Provider UserInfo endpoint is not configured. Use 'quarkus.oidc.user-info-path' if the discovery is disabled.]

Our configuration prior to Quarkus 3.10 looked like this:

quarkus:
  oidc:
    "https://oidc.eks.eu-central-1.amazonaws.com/id/ABCDEF123456":
      auth-server-url: "https://oidc.eks.eu-central-1.amazonaws.com/id/ABCDEF123456"
      token:
        forced-jwk-refresh-interval: 0S
        allow-jwt-introspection: false
        allow-opaque-token-introspection: false
        audience: sts.amazonaws.com
    auth-server-url: https://auth.acme.com/auth/oauth2/realms/root/realms/intranetb2x
    token:
      refresh-expired: true
      refresh-token-time-skew: 10M
    application-type: web-app
    client-id: ${OIDC_CLIENT_ID}
    credentials:
      secret: ${OIDC_CLIENT_SECRET}
    authentication:
      java-script-auto-redirect: false
      redirect-path: /app/ui
      user-info-required: true
      scopes: profile microprofile
    roles:
      source: userinfo
    token-cache:
      max-size: 1000
      time-to-live: 5M
      clean-up-timer-interval: 1M
    token-state-manager:
      split-tokens: true
    logout:
      path: /app/logout
      post-logout-path: /app/ui

The failure can be worked around by explicitly disabling user-info-required for the EKS tenant. Therefore, I'm not sure whether this is a bug actually. But it's a little nuisance since such a configuration wasn't required previously. You might argue that most users will rather have a single OIDC provider and so they are less likely to run into this problem, therefore this might still be worth it 😅 But maybe we could have some smartness to avoid the failure in this scenario?

[sberyozkin]

Hi @markusdlugi

If you have multiple providers securing the endpoint code which has UserInfo injected then Quarkus can check if a given tenant has a userinfo endpoint supported, before setting user-info-required. But I wonder if it would complicate things and raise more questions, for example, what if UserInfo is injected but a single provider only is used and it has no UserInfo, should we fail or warn.

This recent minor enhancement has been done to address probably the most often heard concern, does Quarkus OIDC has too many properties to set ? This is a perfect example where users can rightly feel annoyed, by thinking something along these lines: we have already expressed an intent that UserInfo is required by having it injected in the code, and yet we have to express this intent twice by enabling this property while we don't have to do it for other parts of Quarkus, where the requirements can be detected at the build time by analyzing the endpoint source code.

So, IMHO, having user-info-required=false is clean and makes it obvious that on the path secured by this tenant, no userinfo will be requested, and indeed, I'd consider it is being a rare case. which can be avoided at the code level where UserInfo is requested using Arc or accessed as a userinfo attribute from SecurityIdentity in endpoint methods which need it.

In fact I've just looked at the code and it is done at the build time - and we can not detect that early if the provider has UserInfo supported or not.

My preference is to update the 3.10 migration guide to highlight this update as a breaking change.
Reverting it would feel like we will revoke the optimization for 95% of OIDC users

Does it sound reasonable to you ?

[markusdlugi]

@sberyozkin, are you sure this was already part of Quarkus 3.9? We were previously on Quarkus 3.9.4 and there we did not notice this problem.

[sberyozkin]

@markusdlugi Oh yea, it is this one, #39486 which had an impact, the original one affects a single default configuration only and therefore has no side-effects.
So I'll update the 3.10 guide instead for now, and maybe we'll agree with Michal to avoid any migration effort for this case, thanks

[michalvavrik]

Hey Michal, do you think we can delay requesting user-info-required=true in this case until we know in the OidcRecorder that OidcConfigurationMetadata.getUserInfo() != null, if it is not null - do enable this property, if it is null, then may be do nothing as this UserInfo may be just not used at all ? I.e, instead of enabling at build time, we indicate with some internal property that we only intend to do it at runtime, but only if the provider supports the UserInfo endpoint. What do you think ?

User info is request when required, therefore feature validate / get user info if injected would change to validate / get user info if user info endpoint uri is present (either discovered or set explicitly) and user info injected. I don't see an issue in this approach. Let's convert this question to issue.

• https://github.com/quarkusio/quarkus/blob/main/extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcIdentityProvider.java#L231
• https://github.com/quarkusio/quarkus/blob/main/extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcIdentityProvider.java#L124

Is metadata.getUserInfoUri() != null at this point https://github.com/quarkusio/quarkus/blob/main/extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcRecorder.java#L544 reliable indicator that user info should be required if an injection point had been detected?

[sberyozkin]

@michalvavrik I'd like to consider this very specific case where we try to help users do a simpler configuration - if we detect the UserInfo injection point - then users do expect UserInfo be acquired in most cases, which is indeed the case in this issue, and therefore Quarkus sets user-info-required=true for the user. IMHO this is good, but if one of the tenants does not support UserInfo then we actually force such users add user-info-required=false which, even though it is a rare case, it kind of cancels the original improvement.
So for this issue alone I'd only like to have a minor update which can be backported to 3.10, so that I can drop the breaking change label, and the update I'm thinking about in this case is not to set user-info-required=true at build time, but only if we detect the provider actually supports UserInfo.

Sorry, if it is what you had in mind as well.

Is metadata.getUserInfoUri() != null at this point https://github.com/quarkusio/quarkus/blob/main/extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcRecorder.java#L544 reliable indicator that user info should be required if an injection point had been detected?

Yes, if we have some indicator the injection is available at this point, we know the provider supports it, but user-info-required is not configured explicitly, then we should set it at this point only.

Do you agree with it ? I'll open an issue now to discuss further

[michalvavrik]

Sounds good, let's discuss details in the #40434.