Using OAuth2 Providers to Log Into Your FileMaker Apps

By October 10, 2019 October 11th, 2019 7 Comments

Ever since FileMaker 16 we have been able to use three OAuth Providers to authenticate users: Microsoft Azure AD, Google, and Amazon.

Steven Blackwell and I have just released a white paper that describes how to use even more OAuth providers. We have thoroughly documented the process to make this work, with the help of Claris staff, and it works with FileMaker Server 17 and 18, in all products: FileMaker Pro, Go, and WebDirect.

We have tested with Ping, Okta, Auth0, OneLogin and MiniOrange. We are confident that given the few constraints that we outline in the white paper; you can make use of pretty much any OAuth provider that you want to work with.

All of the providers we have tested support group-based authentication (like Microsoft Azure AD does) so you do not have to create individual accounts in your FileMaker files.

Here are some WebDirect screenshots of two of our servers:

Screenshot of login that allows user to sign in with the Auth0 or Okta OAuth providers

Figure 1. Sign in using the Auth0 or Okta OAuth providers

Screenshot of the login that allows user to sign in with the Mini Orange OAuth provider

Figure 2. Sign into server with the MiniOrange OAuth provider


OAuth2 White Paper

Get the white paper co-authored with Steven H. Blackwell.

FileMaker DevCon 2017 Presentation

For the existing features to use Microsoft Azure AD, Google and Amazon accounts as your OAuth provider, watch my 2017 DevCon presentation and the extensive walk-through that accompanied it.

Reach out to us or leave a comment below when you have questions about using OAuth providers in your solutions and we will be happy to help.

Wim Decorte

Wim Decorte

Wim is a Senior Technical Solution Architect at Soliant. He is a FileMaker 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 and 18 Certified FileMaker Developer and the author of numerous Tech Briefs and articles on FileMaker Server. Wim is one of the very few multiple FileMaker Excellence Award winners and was most recently awarded the FileMaker Community Leader of the Year award at the 2015 FileMaker Developer Conference. He is also a frequent speaker at the FileMaker Developer Conference and at FileMaker Developer groups throughout the world. In addition to being a renowned expert on FileMaker Server, Wim also specializes in integrating FileMaker with other applications and systems. His pet project is the open source fmDotNet connector class that he created.


  • Currently having an issue with Google’s Oauth 2.0 implementation. Using FM Server, Client and Webdirect. When you login to a solution using Google, and you quit out for 40 min, an hour, 12 hours, 2 days, and you log back in, Google auth does not require a password. It lets you right in. I have gotten on the phone with google twice and have not yet reached out to Filemaker although I do not think this issue is on the Filemaker side. Through admin console, the settings are for 20 minute threshold before requesting the password again. This seems not to apply to Filemaker. Any ideas on how to solve what a appears to be a monstrous security hole?

    thanks, in advance,

    • Wim Decorte Wim Decorte says:

      See the conversation we’re already having at
      Each OAuth provider sets the validity of the token to a certain amount of time. I have not seen it where you can log into FM without being prompted for credentials for more than day though. The most I’ve seen for a token validity is about 10 hours or so. In general: the authentication is valid for a certain amount of time is something to consider everywhere that OAuth is used, not just for FM. Which is why not leaving machines unattended while being logged in is a huge deal and is an issue to tackle outside of trying to set a time limit. As long as there is a time limit the core issue will remain.

  • I started that discussion 🙁
    But thanks for telling me about me because sometimes i do forget who i am. LOL.
    I suppose that there is no way to run a script through Filemaker on close window that would log out of Google or slay the token? Provided that you cannot adjust the time of the token through google which seems kinda bananas.

    • Wim Decorte Wim Decorte says:

      You could probably find some code that uses JavaScript or a REST API call that you can use. But it somewhat goes against the grain of why people use OAuth SSO. You’ll find plenty of discussions around this when you Google the topic. From Google’s point of view, a third party app (FM) should not force Google to clear its session. End user can do that on if he likes. By choosing a 3rd party identity provider and especially one where the same session can be used across many services, you’re choosing to play by their rules. By forcing a Google logout you would also for instance forcing your users out of their Gmail sessions or any other Google services they are running. That will get old in a hurry for your users. It’s the old security-vs-convenience argument…

  • I believe that the rules for APIs are outside the realm of Gsuite’s basic structures. According to a programming forum, the API sends an end of a session after one hour. It is up to the programmer of the third party application as to how to handle that error in their code. It appears that the way Filemaker has chosen to handle that code, is by auto logging the user back in, perhaps relying on a browser’s cached settings, not sure. But I do believe that this is hardcoded into Filemaker Server where the API’s are stored. Of course, I am guessing all of this based on some preliminary research.

    I know that it is outside of the Gsuite model, as I use several third party web apps that rely on Google Oauth. When I am logged out of them after a period of inactivity, this has no effect on my Gsuite accounts that relate to the third party account I am logging in as (mail, contacts, calendar).

    I spoke to Google and their API is set to request a password after an hour of inactivity (they even confirmed if for the domain in question), however, this doesn’t happen with Filemaker and I am trying to figure out why not.

    I have Googled a whole bunch and have stumped both Google and Filemaker support. But I know there is an answer somewhere. It just might be that I have to program the answer myself, which would kind of not be my favorite answer.

    Thanks for trying to help. I appreciated all the help I can get.

  • Avatar Sandra Seilmann says:

    Hi Wim,

    I followed your DevCon 2017 Presentation all the way through.
    Thanks for these deep insights.

    I’ve set up a test in our environment (FM17) using Microsoft oauth and it’s working ok.
    Unfortunately it only works one time (per browser used).
    When I the external login the first time, on my Windows system egde opens and asks for permission to open https://fms.[…]
    After I click “open” everything works and I can enter the Filemaker file.

    When I try this a second time, the browser acts the same, but after I click “open” nothing happens.
    I tried other browsers (Firefox, Chrome and (beware) an old IE). Always the same: It works once, but not a second time.

    I fiddled around with deleting cookies and resetting the whole browser. Sometimes it works again, sometimes not.

    Have you ever heard of this behaviour?


    • Wim Decorte Wim Decorte says:

      Hi Sandra,

      No, haven’t seen that happen before. The OAuth mechanism from FM’s perspective clearly works but it certainly sounds like something related to the browsers is running interference. Does it happen on other machines as well? Does it happen when you create a new OS account on your machine and try from there?


Leave a Reply

Need to adjust your business processes quickly? We're helping clients use technology to keep their teams productive and running smoothly in these times of uncertainty. Our team can guide yours if you need help in these areas.

Talk to a Consultant