Devservices keycloak admin suddenly "Https required"

[col-panic]

I was working with keycloak devservices for quite a while, providing my own realm. Now all of a sudden, I only see

But this is the main login - which always worked?!

My custom realm is not even initialized at all saying Realm myrealm can not be created 401 - Unauthorized (somewhere hidden I see that it is also referrring to HTTPS required)

Container quay.io/keycloak/keycloak:26.2.4 started in PT9.86908S

Quarkus is 3.23.4

I found this old issue #27818 but no conclusion. I tried to find the initial realm or the source of the https setting - which as said seems suddenlty to have come up?!

[quarkus-bot[bot]]

/cc @geoand (devservices), @pedroigor (keycloak), @sberyozkin (keycloak)

[col-panic]

2025-07-14 10:44:50,558 ERROR [io.qua.dev.key.KeycloakDevServicesProcessor] (build-31) Admin token can not be acquired: java.lang.IllegalStateException: Retries exhausted : 4 attempts against 1752482692553/1752482692294 expiration
        at io.smallrye.mutiny.helpers.ExponentialBackoff$2.lambda$apply$0(ExponentialBackoff.java:120)
        at io.smallrye.context.impl.wrappers.SlowContextualFunction.apply(SlowContextualFunction.java:21)
        at io.smallrye.mutiny.groups.MultiOnItem.lambda$transformToUni$6(MultiOnItem.java:278)
        at io.smallrye.mutiny.operators.multi.MultiConcatMapOp$MainSubscriber.onItem(MultiConcatMapOp.java:117)
        at io.smallrye.mutiny.subscription.MultiSubscriber.onNext(MultiSubscriber.java:61)
        at io.smallrye.mutiny.operators.multi.processors.UnicastProcessor.drainWithDownstream(UnicastProcessor.java:108)
        at io.smallrye.mutiny.operators.multi.processors.UnicastProcessor.drain(UnicastProcessor.java:139)
        at io.smallrye.mutiny.operators.multi.processors.UnicastProcessor.onNext(UnicastProcessor.java:205)
        at io.smallrye.mutiny.operators.multi.processors.SerializedProcessor.onNext(SerializedProcessor.java:104)
        at io.smallrye.mutiny.subscription.SerializedSubscriber.onItem(SerializedSubscriber.java:74)
        at io.smallrye.mutiny.subscription.MultiSubscriber.onNext(MultiSubscriber.java:61)
        at io.smallrye.mutiny.operators.multi.MultiRetryWhenOp$RetryWhenOperator.onFailure(MultiRetryWhenOp.java:127)
        at io.smallrye.mutiny.subscription.MultiSubscriber.onError(MultiSubscriber.java:73)
        at io.smallrye.mutiny.converters.uni.UniToMultiPublisher$UniToMultiSubscription.onFailure(UniToMultiPublisher.java:104)
        at io.smallrye.mutiny.operators.uni.UniOnItemTransform$UniOnItemTransformProcessor.onItem(UniOnItemTransform.java:40)
        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:403)
        at io.vertx.ext.web.client.impl.HttpContext.execute(HttpContext.java:385)
        at io.vertx.ext.web.client.impl.HttpContext.next(HttpContext.java:363)
        at io.vertx.ext.web.client.impl.HttpContext.fire(HttpContext.java:330)
        at io.vertx.ext.web.client.impl.HttpContext.dispatchResponse(HttpContext.java:292)
        at io.vertx.ext.web.client.impl.HttpContext.lambda$null$6(HttpContext.java:510)
        at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:270)
        at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:252)
        at io.vertx.core.impl.ContextInternal.lambda$runOnContext$0(ContextInternal.java:50)
        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:472)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998)
        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)
Caused by: java.lang.RuntimeException: {"error":"invalid_request","error_description":"HTTPS required"}
        at io.quarkus.devservices.keycloak.KeycloakDevServicesUtils.getAccessTokenFromJson(KeycloakDevServicesUtils.java:72)
        at io.smallrye.context.impl.wrappers.SlowContextualFunction.apply(SlowContextualFunction.java:21)

[col-panic]

I did re-configure my own realm, but this does not even get loaded on startup! I'm trying to figure out for like 2 hours what I could have else done, but it makes no sense to me! It fails already while it should initialize the master realm! My own custom realm can not be loaded, so it couldn't possibly introdue the error.

I did clean sweep all docker images multiple times - I don't think that keycloak does store the realm configuration somewhere outside its docker image?!

[col-panic]

Maybe keycloak/keycloak#30112 (comment) a very recent report - I'm on OS X Don't know how to connect this to devservices however

[col-panic]

And somehow mentioned here keycloak/keycloak#39144

[col-panic]

Docker console

./kcadm.sh config credentials --server http://localhost:8080 --realm master --user admin --password admin
./kcadm.sh update realms/master -s sslRequired=NONE

makes it possible to login afterwards. So somehow it seems to consider the requests coming from "external" - I don't know how keycloak determines who is external. Maybe a recent docker update changed behaviour here?

[col-panic]

Similar problem reported here - seems to hit on this use case too - keycloak/keycloak#25350

[col-panic]

Found a solution - somehow this seems to have been intefering through a Docker update, after enabling the following setting

keycloak acts again as required - not considering our requests to be external anymore!

[col-panic]

WHAT THE - it worked for a short while - now its coming again?!?!

I hit Restart with the docker daemon then it works again - I guess something is terribly wrong with docker here ...

[col-panic]

Something with cookies?! Its all very wierd but I could get a login work again by deleting all cookies!

[sberyozkin]

@col-panic As far as Keycloak devservice is concerned, you can also choose the start up command sequence, for example:

https://github.com/quarkusio/quarkus/blob/main/integration-tests/oidc-mtls/src/main/resources/application.properties#L43.

FYI, management of cookies created by Keycloak itself is not controlled anywhere in Quarkus at all...