Hi Dmitry, thanks a lot for this elaborate clarification. :) It is clear to us what roads we can follow now. First, I asked this question before on stackoverflow. https://stackoverflow.com/questions/53192776/how-to-change-authentication.... Is it ok if I add your reply as an answer there (I will only put there relevant parts)? I believe there will be other people asking the same question... Secondly, considering your recommended way (we love bulletproof solutions ;-)), a Keycloak server, I see I have two options: the full server or the Wildfly add-on. We use EAP 7.1. Can we use the add-on on our server? I also noticed that on the download page you do not recommend this for production use. So I was taking into consideration to install the full Keycloak server. But can we use this server then also to deploy our application? It seems to me that it should be possible since the Keycloak server has a fully featured standalone folder... Of course, we want to avoid to run two EAP instances, if possible ;) Regarding the Intuit question, I am not sure. It is another department who is responsible for this, I am just in the development team. But it could be they use Intuit behind the scenes. We only receive stuff like authentication url, clientId and secret and so on and we have to make it work :-) The well-known configuration we received from them, does look a lot like yours. Thirdly, I will make a JIRA issue for this. Or should I wait first a reply from the Keycloak developers? To be honest, it's the first time I use a mailing list... No idea who can reply on this email. KR, Fabrizio Usai ________________________________________ Van: Dmitry Telegin <dt(a)acutus.pro&gt; Verzonden: vrijdag 9 november 2018 04:45 Aan: Usai, Fabrizio; keycloak-user(a)lists.jboss.org Onderwerp: Re: [keycloak-user] OpenID Java Adapter: configuring keycloak to use an IDP different then Keycloak Server Hello Fabrizio, Indeed, string templates like "/realms/{realm-name}/protocol/openid-connect/auth" are hardcoded into Keycloak adapters [1] [2]. Luckily, there seems to be a workaround. In Keycloak, there is a mechanism for multitenancy [3]; it requires you to supply a resolver that would return a KeycloakDeployment instance based on request parameters. One of its bonus features is that you can completely redefine the behavior of KeycloakDeployment. For example, you can extend org.keycloak.adapters.KeycloakDeployment and override its resolveUrls() method, to make the URLs point to your 3rd party IDP. This approach doesn't require any modifications to the adapter code, so I'd recommend you start with it. However, I wouldn't rule out further incompatibilities that could pop up. Another option is installing an intermediary Keycloak (server), configuring brokering to 3rd party IDP and pointing your adapter to Keycloak. Though sounds like an overkill, it's a bulletproof solution that should work 100% (and it also has some other benefits). There are of course other options like using 3rd party IDP's equivalent for Keycloak adapter (is it Intuit BTW?), or using other OpenID Connect Java libraries [4], or even proxy-level adapters like apache-mod_auth_openidc [5] or Keycloak Gatekeeper [6]. But I understand that this would probably require code rewrite, so you should consider these options only as the last resort. As for SAML and why it used to work: Keycloak adapter uses standard SAML SP metadata for configuration, which defines URLs strictly and unambiguously; here we need to admit that SAML is more mature and feature-complete. OIDC, on the contrary, allows for some freedom. At the moment, Keycloak OIDC adapter doesn't use any standard metadata, but rather generates URLs using hardcoded templates. I think Keycloak adapter could use OIDC's rough equivalent for SAML metadata, namely "well-known" URLs. You can experiment with your IDP and append ".well-known/openid-configuration" to its URL. If my conjecture about Intuit is correct, then it should look like this: https://oauth.platform.intuit.com/op/v1/.well-known/openid-configuration In theory, Keycloak OIDC adapter could ingest this metadata instead of hardcoding URL templates. To me, this could be a valuable addition, but surprisingly I don't see any related JIRA issue. Maybe Keycloak developers could give us some feedback. Cheers, Dmitry Telegin CTO, Acutus s.r.o. Keycloak Consulting and Training Pod lipami street 339/52, 130 00 Prague 3, Czech Republic +42 (022) 888-30-71 E-mail: info(a)acutus.pro [1] https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/k... [2] https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-co... [3] https://www.keycloak.org/docs/latest/securing_apps/index.html#_multi_tenancy [4] https://openid.net/developers/certified/ [5] https://github.com/zmartzone/mod_auth_openidc [6] https://github.com/keycloak/keycloak-gatekeeper On Thu, 2018-11-08 at 14:13 +0000, Usai, Fabrizio wrote: