Error trying to sing up with google account in local machines

Hi, we have upgraded our keycloak service image from v.8 to v.12… all is working ok but we’re not able to sign up / login in our local dev environment… Nevertheless, it works in our test and production environments (deployed in Google cloud). It’s important for us to spin up all the services locally so we can debug everything properly…

The error arises after accepting the google oauth dialog and redirected to the local URL: http://localhost:8080/auth/realms/pi-top/broker/after-first-broker-login?session_code=...
The keycloak UI ${message.summary} only says “Unexpected error when authenticating with identity provider” and the local container logs contains this error:

06:38:47,534 ERROR [] (default task-6) identityProviderUnexpectedErrorMessage: java.lang.NullPointerException
        at org.keycloak.keycloak-model-jpa@12.0.4//org.keycloak.models.jpa.UserAdapter.grantRoleImpl(
        at org.keycloak.keycloak-model-jpa@12.0.4//org.keycloak.models.jpa.UserAdapter.grantRole(
        at org.keycloak.keycloak-model-infinispan@12.0.4//org.keycloak.models.cache.infinispan.UserAdapter.grantRole(
        at org.keycloak.keycloak-services@12.0.4//
        at org.keycloak.keycloak-services@12.0.4//

And this warning:

06:38:47,584 WARN  [] (default task-6) type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=pi-top, clientId=further, userId=******, ipAddress=, error=identityProviderUnexpectedErrorMessage, identity_provider=google,, code_id=d5a71066-b362-4ca4-8dbe-6444050c8159,, authSessionParentId=d5a71066-b362-4ca4-8dbe-6444050c8159, authSessionTabId=B89wWhc3RFA

We suspect that it could be related with the realm configuration, baseUrl, rootUrl, adminUrl, etc… but we’ve tried to change many of the realm parameters without success. Any help will be appreciated, thank you!

Aren’t there backchannel calls that require a publicly routable domain?

@raultruco Can you share your config and what you are trying to achieve? Sounds like you’ve got Google set up as a your IdP. Are you using the standard Keycloak Google “social login”, or are you using generic OIDC or SAML?

@melancholia Assuming it’s a standard flow, no, there is no requirement for a publicly routable domain, as it all happens through browser redirect.


@xgp, @melancholia We’ve got an Identity Provider set up for Google in keycloak… it actually worked on localhost before updating from v.8 to v.12 and it even works with v.12 on out test environment (google cloud with a publicly routable domain).
We’re importing all the config from a .json file previously exported from the UI. This is the “identityProviders” entry:

      "alias": "google",
      "displayName": "Google Classroom",
      "internalId": "6a5aa48d-f90d-4492-8325-0ab6b9e317ef",
      "providerId": "google",
      "enabled": true,
      "updateProfileFirstLoginMode": "on",
      "trustEmail": true,
      "storeToken": true,
      "addReadTokenRoleOnCreate": true,
      "authenticateByDefault": false,
      "linkOnly": false,
      "firstBrokerLoginFlowAlias": "first broker login",
      "config": {
        "offlineAccess": "true",
        "clientId": "*********",
        "clientSecret": "**********",
        "defaultScope": "profile email openid",
        "guiOrder": "1",
        "useJwksUrl": "true"

This is our client configurations:
Broker client:

After accepting the oauth consent screen saying " Further wants to access your Google Account" it’s redirected to:

That’s the url where the error come up…

We have the google side set up with http://localhost:8080/auth/realms/pi-top/broker/google/endpoint as an authorized redirect url, and it was working for us in keycloak v8 but not v12…

Many thanks…

I am afraid I don’t have a ready answer to your query. An apparently similar config is running on our v12.0.4 (it’s on a publicly routed domain; however as @xgp mentions above, it would not mattter).

Were there any out-of-the-box setting changes for the ‘first browser login’ Authentication flow with the version upgrade and/or customization?

Can you try setting it up on the local instance from scratch, rather than importing the config, and see if that makes a difference?

Thank you guys for your responses… In the end we got it by adding a mysterious roles called “read-token” here:

1 Like