AnsweredAssumed Answered

Microsoft Azure oAuth Works for FileMaker Pro, not WebDirect

Question asked by EdwardMcPikeJr on Oct 16, 2018
Latest reply on Oct 17, 2018 by EdwardMcPikeJr

Issue:  Just implemented Microsoft Azure oAuth into our solution over the weekend and the "Sign in with Microsoft" button is not appearing on WebDirect.  To pour salt in the wound, it's causing a 30-second delay for ANY login window to appear when using a custom URL.


Specs (for both production and test servers):  FileMaker Server 16.0.4 on Windows Server 2008 R2 Standard SP1; 32GB RAM; plenty of HD space


Before putting oAuth on our production server, we tested it thoroughly on our test/dev server.  Worked fine.  FileMaker Pro was very snappy, as was WebDirect.


After moving it to production, FileMaker Pro is snappy when using the Microsoft oAuth login, but WebDirect is awful.  It sits there for close to 30 seconds, like it’s trying to figure out what authentication window to produce, then produces the regular one with no "Sign in with Microsoft" button.  Once that window finally loads, you can log-in with your local FileMaker account and the log-in process works just fine.  The database performs as expected from that point on.


We do a bit of a redirect - we have our clients land on a splash page where we have a login button - that way we can control the log off screen as well.  So below are the URLs we use (with domain changed, of course):


These work, but we don't give this URL to our clients:


This does not work from WebDirect:


FileMaker Pro 17 access works fine from both servers.


Very odd that it works fine on one and not the other.  Going to dig back through the IIS settings to see if there’s anything that doesn’t match between the servers.  Our IT department has checked that the settings for the Azure Applications created for each match.  We've even played with adding multiple response URLs, using a wildcard after the domain.


We have watched wimdecorte's video from Devcon 2017 a couple times to make sure that was all done correctly.  The URL he posted here helped as well: - after reading this document that he posted (, I thought it might be related to our redirects, but I still come back to the fact that it works on one server and not the other.  They are both behind the same firewall, so same rules apply.


I am re-re-reviewing all of our settings, but if anyone can point me in the right direction, I would greatly appreciate it.



Ed McPike