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

[VinhNGuyen05]

Work for me too.
Thank you (MacOs, M1)

[zer0origin]

Work for me too.
Thank you (MacOs, M1)

You're welcome

[johncardiologs]

I was having this issue too.

My docker compose file uses localstack, and follows the recommendations here for networking: https://blog.localstack.cloud/2024-03-04-making-connecting-to-localstack-easier/

The compose file looked something like this:

services:
  db:
    image: postgres:15
    volumes:
      - postgresql_data:/var/lib/postgresql/data
      - ./config/db/init.sql:/docker-entrypoint-initdb.d/init.sql
    environment:
      POSTGRES_HOST_AUTH_METHOD: trust
    networks:
      aws-local:
    dns:
      - 10.255.0.253
    localstack:
    image: localstack/localstack:3
    ports:
      - "4566:4566"            # LocalStack Gateway
      - "4510-4559:4510-4559"  # external services port range
    environment:
    # etc.
  keycloak:
    build:
      context: ../my-keycloak-repo
    command:
      - kc.sh
      - start-dev
      - --verbose
      - --spi-email-template-provider=freemarker-plus-mustache
      - --spi-email-template-freemarker-plus-mustache-enabled=true
      - --spi-theme-cache-themes=false
    environment:
      KC_DB: postgres
      KC_DB_URL_HOST: db
      KC_DB_PASSWORD: keycloak
      KC_DB_USERNAME: keycloak
      KC_DB_SCHEMA: public
      KC_LOG_LEVEL: INFO
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: password
    ports:
      - 8081:8080
    depends_on:
      - db
    networks:
      aws-local:
    dns:
      - 10.255.0.253

networks:
  aws-local:
    ipam:
      config:
        - subnet: 10.255.0.0/24

Here's what my docker desktop config looked like (latest version for macOS silicon at time of writing `v.48.0`)

I noticed the following in the keycloak docs:

External requests Users can interact with Keycloak without SSL so long as they stick to private IPv4 addresses such as localhost, 127.0.0.1, 10.x.x.x, 192.168.x.x, 172.16.x.x or IPv6 link-local and unique-local addresses. If you try to access Keycloak without SSL from a non-private IP address, you will get an error.

When I changed the IP subnet in my aws-local docker compose sub network to begin with 192.168.x.x, and I visited http://localhost:8081 in my browser, everything immediately started working again for me. Not exactly sure why, hope this helps someone.

[sberyozkin]

Thanks, I'll need to go through the list of various successful attempts to resolve it and have some summary in the docs

[tinjohn]

I don't think it matters what has actually changed; restarting it makes it work again. I experience the problem almost every time after running docker compose down and up again. Due to the post, I check or uncheck Enable host networking and hit Apply & Restart. It works until I run the down and up commands in the command line.

[patateskafa]

I can confirm this issue persists.