June 16, 20205 yr We upgraded to FMS19 today and Google OAuth no longer works. The select an account screen comes up in a Browser, the redirect to our server is called and then there is no error and the DB is not logged in. It just leaves you at the login window. You could repeat this process over and over. If you reload the redirect URL you get an Authentication Failed error which I what I would expect if the authentication was failing. I think the original auth request is successful but does not open the DB. I also tested on another server with the same results.
June 16, 20205 yr I've been using FMS19 extensively with OpenID Connect OAuth providers so I know the underlying mechanism works. I would suggest using https://oidcdebugger.com/ to initiate an auth request and complete the second step with Postman so that you have a chance to inspect the id_token that you get back. You'll need to add https://oidcdebugger.com/debug to your list of Redirect URLs on the Google side. 19 minutes ago, RyanB said: It just leaves you at the login window Which one? The FM one or the Google one? If you changed the DNS name of your server, make sure to update the redirect URLs on the Google side.
June 16, 20205 yr Author I was referring to the FM Login Window. No DNS names have changed. I will check out oidcdebugger. That might be just what I need. Thanks
June 16, 20205 yr If you the FM login stays open then it feels like FMS is not receiving the redirect from Google.
June 16, 20205 yr Author I thought that too and checked our firewall. Nothing should be getting blocked so I am not sure why it is stopped. Is FMS 19 using any new ports? I have never used https://oidcdebugger.com/ I am not sure what to put for Authorize URI (required), Response type (required) , or Response mode (required)
June 17, 20205 yr Check out addendum 4 of our series of white papers: It describes how to use oidcdebugger and postman to simulate the whole process and to inspect the id_token. And no: no different ports because this all goes on port https (443), none of it is FMS-specific.
June 17, 20205 yr Author Thanks. I have not worked through the document yet but I have discovered a possible cause. We use internal DNS in our office which points traffic to our FM Server FQDN to the LAN IP. Oauth is working fine outside the Office and if I edit my host record to resolve to the FMServer using the public IP Oauth works fine. This all worked before the upgrade. It makes no sense because DNS resolves fine internally and externally.
June 17, 20205 yr Yes, would be weird. The only thing I can think of are the SSL issues with Comodo that started around June 1st, if your FMS SSL cert was affected by the expiry of the intermediate bundle from Sectigo then perhaps that is what is in play and the FMS19 upgrade is a red herring?
Create an account or sign in to comment