This cannot work: as a user you can make your Firefox truststore accept imported certificates. But this will not convince your Keycloak server who doesn't know about the origin of certificates.
In Keycloak you configure "redirect URLs" u sing HTTPS. The Keycloak server should find a Root CA or Intermediate CA Certificate in its truststore that matches the URL.
For further analysis open a web console window in your Firefox as visible from the attached screenshot. This can give more evidence, for example about CORS errors.
I resolved my problem, my keycloak had an invalid certificate, I made it as a POC.
I also made a PKCS12 truststore including my keycloak CA and added it in JOC conf.
Everything is working fine now.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We also face OIDC problems since version 2.7.5 or 2.8.0: We use Microsoft EntryID as OIDC provider. All worked fine with 2.7.4. Since 2.7.5 / 2.8.0 we aren't able to log in anymore (we are thrown back to the login screen). The joc.log shows
INFO c.s.j.c.JOCDefaultResponse - URL: https://login.microsoftonline.com/REDACTED/oauth2/v2.0/token
ERROR c.s.j.c.JOCDefaultResponse - JocBadRequestException: com.sos.joc.exceptions.JocBadRequestException: 401 Unauthorized
com.sos.joc.exceptions.JocBadRequestException: 401 Unauthorized
at com.sos.auth.oidc.GetToken.getJsonStringFromResponse(GetToken.java:175) ~[sos-webservices-joc-global-2.7.5.jar:?]
at com.sos.auth.oidc.GetToken.getJsonStringFromPost(GetToken.java:120) ~[sos-webservices-joc-global-2.7.5.jar:?]
at com.sos.auth.oidc.GetToken.getJsonStringFromPost(GetToken.java:102) ~[sos-webservices-joc-global-2.7.5.jar:?]
at com.sos.auth.oidc.GetToken.getJsonObjectFromPost(GetToken.java:97) ~[sos-webservices-joc-global-2.7.5.jar:?]
at com.sos.auth.classes.SOSServicePermissionIam.loginPost(SOSServicePermissionIam.java:199) ~[sos-webservices-joc-global-2.7.5.jar:?]
at com.sos.auth.classes.SOSServicePermissionIam.loginPost(SOSServicePermissionIam.java:267) ~[sos-webservices-joc-global-2.7.5.jar:?]
...
We also run JS7 dockerized. The Java truststore and the system's /etc/ssl/certs directory contain (also) the root cert of the firewall (which does SSL inspection). Our JS7 does not provide SSL itself as we have Traefik (with SSL termination) as reverse proxy in front of it.
I've found this change in the changelog: https://change.sos-berlin.com/browse/JOC-2038 ("Offer token exchange from Relying Party for OIDC Authentication"). Could this be related? Do we have to adjust our setup now?
Best regards
Daniel Winkler
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Daniel,
it is highly probably that this is caused by JOC-2038. The change does not make use of different settings but switches the initiator for the token exchange step in OIDC authentication from the Client browser to the JOC Cockpit application.
This means the final request is now performed from JOC Cockpit's server, not from the Client browser's machine. Can you please check if this is considered by your Traefik configuration?
Best regards
Andreas
Last edit: Andreas 2025-08-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, the Traefik just handles incoming requests, not outgoing requests, so it should not be involved.
Just to be sure: We have to define in Azure which URLs are valid when the EntraID service is called. Which URL does the server use? I've defined it in the "joc_reverse_proxy_url" setting (https://js7.REDACTED/joc) - will it be used? Or is this not relevant at all here?
Best regards
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Daniel,
do not change the configuration for now as it was working before. Our current assumption being that the 401 status code that you receive is due to a mismatched origin header. We do not assume that you did change the Client ID or Client Secret which would explain the 401.
In fact JOC Cockpit adds its URL from the incoming request to the origin header of its outgoing request. This is the Redirect URL you configure in the Identity Provider. Could be that the incoming URL is changed by the proxy. and fails when used by JOC Cockpit for the origin header.
The "joc_reverse_proxy_url" from the Settings is not used. The issue is under investigation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Daniel,
logging requests and responses is helpful for further analysis, which is currently missing. I have provided this as a patch for version 2.7.5; see https://change.sos-berlin.com/browse/JOC-2100
Please use this patch to see more in the authentication-debug.log
Best regards
Oliver
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your responses.
I've added the patch and set the loglevel.
The JS7 EntraID application was configured as "Single Page Application".
What I can see in the logs then:
...
ESPONSE:{"error":"invalid_client","error_description":"AADSTS700025: Client is public so neither 'client_assertion' nor 'client_secret' should be presented. Trace ID: XXX Correlation ID: XXX Timestamp: 2025-08-28 11:24:37Z","error_codes":[700025],"timestamp":"2025-08-28 11:24:37Z","trace_id":"XXX","correlation_id":"XXX"}
We've checked the app, but would read the current settings that it is not marked as public.
I've came across some articles, so we switched from Single Page Application to "Web application". The resulting error message was:
RESPONSE:{"error":"invalid_request","error_description":"AADSTS9002326: Cross-origin token redemption is permitted only for the 'Single-Page Application' client-type. Request origin: 'https://js7.XXX'. Trace ID: XXX Correlation ID: XXX Timestamp: 2025-08-28 11:42:20Z","error_codes":[9002326],"timestamp":"2025-08-28 11:42:20Z","trace_id":XXX","correlation_id":"XXX","error_uri":"XXX"]}}}"}
Can you derive some hints for us?
Best regards,
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Daniel,
thanks for the responses.
Let's go back to the “Single Page Application” setting and try again.
Then you will find a line in the log file with GetOpenIdConfiguration - RESPONSE:{...}
before the login fails.
This response contains values for
"token_endpoint"
"token_endpoint_auth_methods_supported"
Please tell me if the value of "token_endpoint" contains "/v2.0"?
Please post here the value of "token_endpoint_auth_methods_supported".
Best regards
Oliver
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm using JS7 with Docker and I used this image for JOC : "sosberlin/js7:joc-2-8-0" but I'm unable to make the OIDC button work
I added a OIDC-JOC Identity service, I configured my Keycloak URL, Client ID and Client Secret.
But when I click on the new button, nothing happens. It should open a popup with the Keycloak Form.
Any idea ?
I think there is nothing relative to my keycloak conf because with the Authorization Code Flow, it should at least show my KC form.
There is nothing in JOC logs, I changed it to debug, and keycloak (also at Debug level) does not catch anything.
I also checked the anti popup with Firefox but even when I activate it, nothing happens
Thanks,
David
Last edit: David CHOCHOI 2025-08-13
Hi David,
to my knowledge there is no "new" button. Instead, you should find a "Continue with ..." button in the login page as visible from attached screenshot.
OIDC will work only if your JOC Cockpit is configured for HTTPS.
Andreas :
JOC Cockpit is configured for HTTPS and indeed, the button is "Continue with ..."
But the button still not works.
Actually I used the certs available on this page : https://kb.sos-berlin.com/display/JS7/JS7+-+JOC+Cockpit+Configuration+for+Containers
They are not validated with my firefox truststore, maybe it could be an idea to solve that problem...
Edit : Added the CA in my firefox truststore, it doesn't still work...
Last edit: David CHOCHOI 2025-08-13
This cannot work: as a user you can make your Firefox truststore accept imported certificates. But this will not convince your Keycloak server who doesn't know about the origin of certificates.
In Keycloak you configure "redirect URLs" u sing HTTPS. The Keycloak server should find a Root CA or Intermediate CA Certificate in its truststore that matches the URL.
For further analysis open a web console window in your Firefox as visible from the attached screenshot. This can give more evidence, for example about CORS errors.
Hi,
I resolved my problem, my keycloak had an invalid certificate, I made it as a POC.
I also made a PKCS12 truststore including my keycloak CA and added it in JOC conf.
Everything is working fine now.
Thanks
We also face OIDC problems since version 2.7.5 or 2.8.0: We use Microsoft EntryID as OIDC provider. All worked fine with 2.7.4. Since 2.7.5 / 2.8.0 we aren't able to log in anymore (we are thrown back to the login screen). The joc.log shows
We also run JS7 dockerized. The Java truststore and the system's /etc/ssl/certs directory contain (also) the root cert of the firewall (which does SSL inspection). Our JS7 does not provide SSL itself as we have Traefik (with SSL termination) as reverse proxy in front of it.
I've found this change in the changelog: https://change.sos-berlin.com/browse/JOC-2038 ("Offer token exchange from Relying Party for OIDC Authentication"). Could this be related? Do we have to adjust our setup now?
Best regards
Daniel Winkler
Hi Daniel,
it is highly probably that this is caused by JOC-2038. The change does not make use of different settings but switches the initiator for the token exchange step in OIDC authentication from the Client browser to the JOC Cockpit application.
This means the final request is now performed from JOC Cockpit's server, not from the Client browser's machine. Can you please check if this is considered by your Traefik configuration?
Best regards
Andreas
Last edit: Andreas 2025-08-25
Hi Andreas,
Thank you for your fast response.
Well, the Traefik just handles incoming requests, not outgoing requests, so it should not be involved.
Just to be sure: We have to define in Azure which URLs are valid when the EntraID service is called. Which URL does the server use? I've defined it in the "joc_reverse_proxy_url" setting (https://js7.REDACTED/joc) - will it be used? Or is this not relevant at all here?
Best regards
Daniel
Hi Daniel,
do not change the configuration for now as it was working before. Our current assumption being that the 401 status code that you receive is due to a mismatched origin header. We do not assume that you did change the Client ID or Client Secret which would explain the 401.
In fact JOC Cockpit adds its URL from the incoming request to the origin header of its outgoing request. This is the Redirect URL you configure in the Identity Provider. Could be that the incoming URL is changed by the proxy. and fails when used by JOC Cockpit for the origin header.
The "joc_reverse_proxy_url" from the Settings is not used. The issue is under investigation.
Hi Daniel,
logging requests and responses is helpful for further analysis, which is currently missing. I have provided this as a patch for version 2.7.5; see https://change.sos-berlin.com/browse/JOC-2100
Please use this patch to see more in the authentication-debug.log
Best regards
Oliver
Instructions how to apply a patch are available from JS7 - Patches for JOC Cockpit API.
Instruction how to set debug log levels are available from JS7 - Log Levels and Debug Options
Thank you for your responses.
I've added the patch and set the loglevel.
The JS7 EntraID application was configured as "Single Page Application".
What I can see in the logs then:
We've checked the app, but would read the current settings that it is not marked as public.
I've came across some articles, so we switched from Single Page Application to "Web application". The resulting error message was:
Can you derive some hints for us?
Best regards,
Daniel
Hi Daniel,
thanks for the responses.
Let's go back to the “Single Page Application” setting and try again.
Then you will find a line in the log file with
GetOpenIdConfiguration - RESPONSE:{...}before the login fails.
This response contains values for
Please tell me if the value of "token_endpoint" contains "/v2.0"?
Please post here the value of "token_endpoint_auth_methods_supported".
Best regards
Oliver
Hi Oliver,
here is the extract:
Best regards,
Daniel
Hi Daniel,
patches that should solve the problem are attached to https://change.sos-berlin.com/browse/JOC-2102
Best regards
Olli
Great, worked. Thanks for the fast support.
Best regards,
Daniel
Thank you for your feedback and cooperation.
Best regards
Oliver