2

I am following this Keycloak guide to secure a Java desktop application. I have setup the Client as stated:

enter image description here

In my application, when I call loginDesktop(), I get the browser to sign in and I can sign in correctly. But after the sign in, the redirect page says "We are sorry. Page not found":

enter image description here

Other info: Keycloak server is hosted on Google Cloud Run and using a Google CloudSQL Postgres instance for persistence. The docker image from Keycloak is using Keycloak version 16.1.1. I am using Google Cloud SQL proxy to connect to Postgres. Persistence is working correctly - I can login throughout runs.

Any help is appreciated.

Dula
  • 1,404
  • 1
  • 14
  • 29
  • Same problem! Using http://localhost* (with an asterix at the end) and ever since upgrading to Keycloak Quarkus (18) from v16, I get redirected to the "We are sorry" page also. Have not found a workaround. this is for a Java Desktop application also! – AdamE Aug 22 '22 at 16:43
  • I have tried without an asterisk http://localhost and tried 127.0.0.1 (as suggested elsewhere https://stackoverflow.com/questions/45352880/keycloak-invalid-parameter-redirect-uri to no avail but that results in a invalid redirect uri error. – AdamE Aug 22 '22 at 16:51

3 Answers3

3

This is an acknowledged bug in Keycloak, that began with the v16 release, and is as yet unfixed in v17, v18, and v19 releases:

As of this writing, the proposed PR:

to fix this has not yet been approved because they want it implemented differently, as a fix to the KeycloakInstalled Java adapter. (There are comments about the Java adapters being "deprecated" but I do not know enough to know if that is accurate, since it is said if the proposed fix is approved, they will release the fix in an upcoming 19.02 release)

Another proposed solution appears to be one that compiles a custom version of Keycloak Server (or at least a custom KeycloakInstalled Java adapter). The instructions (which I have not tried) for that workaround are in this stack-overflow post

AdamE
  • 606
  • 6
  • 11
1

Note that the documentation address is http://localhost:8080/realms/myrealm/account, where the "myrealm" part of the address has to be the same name as your realm you created. For example, if you created the realm with the name "teste", you should access it at http://localhost:8080/realms/test/account.

Trickster Júnior
  • 96
  • 2
0

If you are using the latest guide, it works with keycloak 17+.

There has been a change in the default url for keycloak server with version 17 (with the quarkus distribution, in fact, which is the default with keycloak17) :https://www.keycloak.org/migration/migrating-to-quarkus

For you this means your keycloak server is deployed on the /auth path, so, in your configuration :

{
  "realm": "desktop-app-auth",
  "auth-server-url": "http://localhost:8081/auth",
  "ssl-required": "external",
  "resource": "desktop-app",
  "public-client": true,
  "use-resource-role-mappings": true,
  "enable-pkce": true
}

auth-server-url should have /auth.

Cédric Couralet
  • 4,913
  • 1
  • 21
  • 21
  • I already have `/auth` at the end of the `auth-server-url`. The login works correctly. It's the redirect after the login that doesn't work. – Dula Apr 14 '22 at 06:44
  • oups sorry, what is the redirection url then ? How is configured your desktop app ? – Cédric Couralet Apr 14 '22 at 07:36
  • I have set the redirect url as `http://localhost` as stated in the documentation. Desktop app is configured exactly as the JSON file you provided except `auth-server-url` points to the Google Cloud Run address. – Dula Apr 16 '22 at 07:40
  • Unfortunately, as pointed out above, this answer is answering another different question. I still have the same problem! Using localhost* (with an asterisk at the end) and ever since upgrading to Keycloak Quarkus (18) from v16, I get redirected to the "We are sorry" page also. Have not found a workaround. this is for a Java Desktop application also. – AdamE Aug 22 '22 at 16:45
  • @Dula any success with this? Anything you can share? – AdamE Aug 22 '22 at 17:01
  • 1
    @AdamE sorry nothing new. Our management decided to go with `auth0` instead so I abandoned the keycloak integration. – Dula Aug 24 '22 at 00:34