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:
Resources
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.
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,
Limore
See the conversation we’re already having at https://community.filemaker.com/en/s/question/0D50H00007PGfKUSA1/how-do-you-specify-a-google-oauth-authentication-time-limit
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.
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 google.com 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.
Limore
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?
Cheers,
Sandra
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?
Wim.
It is interesting to be able to use for example Google account to sign into FileMaker…
However there is also a problem when sending emails from FileMaker server.
This days smtp authentication will not work with Google or Microsoft any more, especially with Google, as they scraping LSA.
Meaning user no longer will be able to lower security settings in their Google account to turn on Less Secure Apps….
Therefore emails will no longer be able to send from FileMaker…
I wonder if this way of authentications, to login to FileMaker server, will also authenticate when sending emails? or this is just to access the FileMaker and nothing else…
Hi Tom,
The big email providers are pushing very hard to get people away from old (and less secure) protocols like SMTP; which is why we’re seeing so many problems with them.
We wrote about that here: https://www.soliantconsulting.com/blog/microsoft-graph-api-filemaker-one/ ; we believe that using the MS365 and Google APIs for reading and sending emails is the way of the future. And that does involve authentication using OAuth. That blog post has a full demo that shows how to do that.
Authenticating users into the FM solution with OAuth is separate and doesn’t automatically solve the email-sending problem. But setting one of up makes it easier to set the other up.
Feel free to reach out to us here or on community.claris.com; we deal a lot with both OAuth authentication into FM solutions and OAuth authentication to use outside services.
Hi Wim,
I’ve successfully followed your instructions to authenticate OKTA with FM (thanks for sharing the process) but have issues with getting AUTH0 to work.
I’m wondering if you got it to work with group authentication?
Also, wondering if that is even possible anymore having found this thread:
https://community.auth0.com/t/how-do-you-manage-user-groups/35897
Hi Dan,
Yes we’ve used groups with Auth0 successfully. We use the “Authorization Extension” for this.
Best regards,
Wim
Thanks Wim.
Hi, is possible to update the whitepaper for auth0 ? i’m not able to make working with fm 19.4.
Hi Andrea,
Did you have it working before with an older version of FileMaker Server?
Best regards,
Wim
Hi Win, nope.. is the first time… i try to follow your withepaper but isn’t simple to match all setting
Hi Andrea, create a new question in community.claris.com and tag me (@wimdecorte) – that’s a better medium for getting you on your way.
Best regards,
Wim
nope, this is the fist time i try to setup auth0 and fms
Hi Wim,
Fast forward to 2023 and FM 19.X. Do we still need:
1) SSL certificate,
2) and a fully qualified domain name?
Regards,
Nashat
Yes, very much so.
Hi Wim,
Can we use a self-signed certificate for oAuth?
Regards,
Nashat
Theoretically yes. But in practical terms you’ll run into trust issues very quickly since you don’t have a “chain of trust” that leads to a root CA that everybody trusts.
Typically we find that trying to make self-signed/self-issued certs work is not worth the $15 it costs to get a commercial SSL cert that just works out of the box.
Thank you very much for your reply.
Regards,
Nashat
Hi Wim,
We have our website https://www.ourcompany.com which has an SSL certificate attached to it. We created a subdomain (subdomain.ourcompany.com) and redirected it to our unsecured FM WebDirect server (http://123.123.123.123/fmi/webd).
Then we configured for Google oAuth using https://www.ourcompany.com as our redirect URL while following the steps in your video. The steps were completed without error, and in the FM Server Administration under External Authentication for Google it showed “Configured”.
However, when we access the FileMaker app it only shows the standard fields for id / password. The login with Google option doesn’t appear.
Your guidance would be appreciated.
Regards,
Nash’at
Hi Nash’at,
This kind of troubleshooting doesn’t lend itself well to this medium, in comments on a blog post. You may want to post this question on community.claris.com or contact us directly to set up a service contract to troubleshoot together.
A couple of thoughts:
– don’t use unsecured http with anything FMS, you will get nothing but security warnings and many browsers will refuse to connect.
– the fact that your www subdomain (website) has an SSL certificate doesn’t mean that traffic to and from FMS is secured. You still need to import an SSL cert into FMS itself and that means you need to use a unique fully qualified domain name for your FMS: say fms.ourcompany.com
– the redirect URL you set in the Google app should be in the format that FMS suggests which translates into your example should be: https://fms.ourcompany.com/oauth/redirect. You cannot use any other URL because FMS needs to grab the code from the first interaction with Google and then call Google to get the tokens.
Hi Wim,
Thank you very much for your patience and guidance.
Regards,
Nashat