oAuth with Keycloak running in Docker on localhost - grant_type error

[HHenle]

Following the instructions in oauth-extensibility-addendum3 (excellent document! - big thank you to the authors) I have (almost) succeeded in getting it up and running on a local machine. This is of course for dev and test only.

My setup is:

MacOSX 10.15.7 (running on a MacBookPro 2,6 GHz 6-Core Intel Core i7)

Keycloak 11.0.2 running in Docker 2.4.0.0

FilemakerServer / FilemakerPro 19.0.1

To make this all work on https://localhost a certificate is required which you cannot get from a CP. Conveniently, installing Keycloak in Docker with

docker run -p 8443:8443 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=password quay.io/keycloak/keycloak:11.0.2

creates a self-signed certificate for https://localhost as part of the installation. When, opening Keycloak in a browser (Safari) from Docker make sure it connects to https://localhost:8443/auth. On the first connection you will get a warning about the non-private connection; allow this and also add the certificate to the keychain.

With this done I followed the instructions from the oauth documents but Filemaker does not accept the authentication from Keycloak. After debugging with oidcdebugger and Postman I narrowed the issue down to this error when sending the token request to Keycloak:

 

{

"error": "invalid_request",

"error_description": "Missing form parameter: grant_type"

}

 

I have gone through the settings in both Filemaker and Keycloak several times but I am stuck to trouble shoot this any further. In Postman, grant_type is set to authorization_code in the body section and the endpoint configuration in Keycloak this is listed as an accepted grant type.

Any help would be greatly appreciated.

 

Thanks, Hubert

 

[Wim Decorte]

We had part of this conversation already on community.claris.com... don't use a self-signed cert and certainly don't use it to try and sign "localhost' as a domain.  Localhost has special meaning in networking.

The problem with self-signed certs is that they may not be trusted by the other machine you're trying to connect from, which defeats the purpose of using HTTPS and SSL to begin with.  So if you insist on using self-signed certs, make absolutely certain that you have that piece working without getting the security warning first.  The fact that your browser stores it in the keychain does not mean that every single part of the auth flow will trust it.

As to the actual error: we can't troubleshoot this without seeing the Keycloak settings.

[HHenle]

Yes, I am referring to that conversation and thought I open a new thread as you suggested but did so on this forum where you initially posted your white papers.

I get the cert issue but as mentioned, my setup is for dev/testing and purely local, using various VMs and Docker. It's not exposed to the internet and therefore I can't have proper certs. Don't think this is a particularly special setup. Also FMS uses its own self signed cert when running locally. 

This is an evaluation exercise for FMS authentication with Keycloak and at this point there is no budget to spin up a remote machine for FMS and/or Keycloak etc. It's all working without any browser warnings up to the point of the failed authentication which appears to be caused by the "Missing form parameter: grant_type" revealed during trouble shooting with oidcdebugger and Postman. The oidcdebugger step is successful, but the POST request from Postman

POST /auth/realms/FMServer/protocol/openid-connect/token HTTP/1.1
Host: localhost:8443
Content-Type: application/x-www-form-urlencoded

code=300aeac3-ced3-4576-a923-3e4a295c6c1d.ddd5ad9e-1553-4907-b150-85d72fe348f9.1a8e49e3-197c-484f-8229-dd6191fbe262&state=Hubert&client_ID=FMS_Skript&redirect_uri=https://oidcdebugger.com/debug&grant_type=authorization_code&client_secret=5db67273-bb74-4b7a-905d-ef34279cb0d2

does produce the error.

I have double-checked my Keycloak settings against the settings in oauth-extensibility-addendum3 and they match (apart from different names used for realm, client, and groups). The only difference I noticed is that on Client Scopes > groups > Mappers > groups setting "Claim JSON Type" is not available in the Keycloak version I have (11.0.2). A settings export is attached.

Again, thanks for taking the time - this is very much appreciated.

realm-export.json

[Wim Decorte]

2 hours ago, HHenle said:

I get the cert issue but as mentioned, my setup is for dev/testing and purely local, using various VMs and Docker. It's not exposed to the internet and therefore I can't have proper certs.

That's a common misconception, but it is a critical one.

Certs are not exclusively meant for anything exposed to the internet.  Certs are used to encrypt the traffic and validate the destination's identity and that is equally critical for traffic that never leaves the network.  Read any security and data breach report and you'll find they all state the same (and have stated for many years): that the vast majority of breaches come from inside the network, not from outside the network.

Thinking that you do not need certs because it is all internal is very very faulty.

Since certs require FQDNs, you do need a local DNS setup. Which is a simple thing to set up and will allow you route traffic to those DNS names internally without relying on outside DNS servers.  That how you can use an existing domain name for LAN traffic.  So if you already have a wildcard cert for an existing domain, use that domain name, it saves you from having to get a new cert.

And lastly: for these kinds of setups when you are developing and testing; it is crucial that you stick as closely as possible to how this will be deployed for real.  So no "localhost" shortcuts or self-signed cert.  Use actual DNS names and actual certs because that will surface anything that has to do with networking that you may not have in your test rig but that you will have when you deploy this.