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...

[philrouvray]

I experienced the same problem. I tried all what has been mentioned above without success. For the record, I write down here how I managed to get back to normal.

First let me give you a little bit of context : I'm on Mac. Docker Desktop installed for years. Updated regularly to the latest version. Kubernetes and Supabase deployed on Docker Desktop for quite some time. I was developing a Quarkus microservice requiring a Keycloak. Everything was working just fine : no problem with Keycloak devservices populated by my own Realm description file.

Then the nightmare : Suddenly, test started failing with 401 - Unauthorized. I did not upgrade my docker desktop, I did not change whatsoever in my code. It started failing just like that. I tried some cleanup on my code side and docker side. Kill and purge everything. It kept on failing !

Finally the light at the end...The solution was to uninstall Docker Desktop "totally". A simple uninstall followed by a new installation starting up from the previous data files was not enough. You have to clean up Docker's directories. A couple of blog entries explain the directories you have to delete in addition to the uninstall process. And then, after a docker desktop re-installation from scratch, everything was back on tracks ! I did not have to change my code. There is no worse waste of time than searching for a bug that doesn't exist...

[iharob-caliza]

Using mac OS for development is a terrible thing to do. But I am forced to do so unfortunately.

[polo7]

I've followed your advice but in less radical manner. I've just updated Docker Desktop to the latest version (4.45.0) and voila "HTTPS required" disappeared.

OS: MacOS Sequoia 15.2, CPU: M4

[zer0origin]

I solved this issue by changing the follow in my docker compose file:

    ports:
      - "8081:8080"

TO

    ports:
      - "127.0.0.1:8081:8080"

[drazen-nikolic]

This worked for me. Thanks. (MacOS, Apple Silicon M1)

[zer0origin]

This worked for me. Thanks. (MacOS, Apple Silicon M1)

No problem