RyanB 0 Posted June 16, 2020 Share Posted June 16, 2020 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. Link to post Share on other sites
Wim Decorte 514 Posted June 16, 2020 Share Posted June 16, 2020 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. Link to post Share on other sites
RyanB 0 Posted June 16, 2020 Author Share Posted June 16, 2020 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 Link to post Share on other sites
Wim Decorte 514 Posted June 16, 2020 Share Posted June 16, 2020 If you the FM login stays open then it feels like FMS is not receiving the redirect from Google. Link to post Share on other sites
RyanB 0 Posted June 16, 2020 Author Share Posted June 16, 2020 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) Link to post Share on other sites
Wim Decorte 514 Posted June 17, 2020 Share Posted June 17, 2020 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. Link to post Share on other sites
RyanB 0 Posted June 17, 2020 Author Share Posted June 17, 2020 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. Link to post Share on other sites
Wim Decorte 514 Posted June 17, 2020 Share Posted June 17, 2020 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? Link to post Share on other sites
RyanB 0 Posted June 17, 2020 Author Share Posted June 17, 2020 We are using a GoDaddy SSL. Link to post Share on other sites
Wim Decorte 514 Posted June 17, 2020 Share Posted June 17, 2020 I do too, including my FMS19s, so that is not the issue then. Link to post Share on other sites
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now