External Authenitcation Not Working after Upgrade

[RyanB 0]

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.

 

[Wim Decorte 509]

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.

[RyanB 0]

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

[Wim Decorte 509]

If you the FM login stays open then it feels like FMS is not receiving the redirect from Google.

[RyanB 0]

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)

 

[Wim Decorte 509]

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.

[RyanB 0]

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.

[Wim Decorte 509]

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?

[RyanB 0]

We are using a GoDaddy SSL.

[Wim Decorte 509]

I do too, including my FMS19s, so that is not the issue then.