OneLogin for FileMaker User Authentication

The Past and Future of Authentication – a Recap. And Introducing OneLogin to Authenticate FileMaker Users

In recent months you have seen quite a few blog articles from us around OAuth authentication for various aspects of the FileMaker platform.

This blog post introduces a new addendum to our white papers and showcases how to use OneLogin to authenticate your FileMaker users. It also consolidates the previous materials into one comprehensive resource on the topic.

We are passionate about security and are specifically intrigued by how authentication keeps evolving. This infographic from the OneLogin team shows the evolution of user identification and where we are heading.

Thumbnail of Infographic from the OneLogin team
Preview of “The Future of Authentication” infographic. View full-size

Needless to say, as developers and consultants, you need to deliver on modern authentication requests from your customers. This includes providing access to your FileMaker apps and giving the user functionality within those apps that require access to other services such as email, calendaring, file sharing, and so on.

Let us summarize some of the resources we have created to help you navigate through these new waters.

Authentication Resources

Before FileMaker 7, you could only use internal FileMaker accounts (in fact, there was not even a username, just a password).

In March 2004, with the release of the FileMaker 7 platform, that was upgraded to username/password combos for an internal account. More importantly, you then had the option to use Windows Active Directory (AD), Apple Open Directory (OD), or accounts and groups in the Operating System of the server to authenticate your users.

Steven Blackwell and I wrote a white paper back in 2004 to document those new AD and OD features, and since then that white paper has been updated a few times, and while the screenshots are a bit dated, all of its content is still valid, and these features work in the current versions of the platform.

The next big functional jump came in May 2017 with the FileMaker 16 platform. This introduced support for three new external Identity Providers (IdP): Microsoft Azure AD, Google, and Amazon, through the use of the OAuth protocol. A short white paper co-authored with Steven Blackwell, and an extensive setup walkthrough for all three providers is here.

You can also watch my 2017 DevCon presentation on External Authentication below:

Since then, we discovered – with the help of the FileMaker developers involved with the FDA and engineering support from Claris – that the underlying mechanism that allows those three OAuth IdP providers to function can be extended to other IdPs as long as they follow the OpenID Connect flavor of OAuth.

Steven Blackwell and I released a white paper in October of 2019 that explains how to use that mechanism and extend the authentication options. That white paper uses Okta as the IdP.

In November 2019, we released an addendum that adds some more technical detail and documents the FDA story where they are using Ping as the IdP as well as using PIV cards to log into the FileMaker solution.

And today, we are adding a second addendum to detail how to use OneLogin as the IdP to authenticate your users.

With this, we have demonstrated that you can use a very wide variety of authentication authorities to let users into your FileMaker solutions. In the collection of white papers linked throughout, you will find guides to set up:

  • Apple Open Directory (individual users or groups)
  • Google (individual accounts)
  • Amazon (individual accounts)
  • Ping (individual users or groups)
  • Okta (individual users or groups)
  • OneLogin (individual users or groups)

And while we have not done a full walkthrough of the setup for them, we have also successfully implemented Auth0 and MiniOrange as IdPs.

FileMaker Cloud Authentications

All of this works with the regular version of FileMaker Server 17 and 18. What about FileMaker Cloud?

The original FileMaker Cloud, introduced in 2016, supported only the three original OAuth providers: Azure AD, Google, and Amazon. It did not support on-premise AD or OD, nor could you use the operating system’s own accounts and groups.

The new FileMaker Cloud launched in October 2019 uses external authentication by default and exclusively through its FileMaker ID. The February 2020 release adds support for Okta and for Microsoft Active Directory Federation Services. You can find a walkthrough for Okta here and for ADFS here. You currently cannot extend these with other providers like you can with the regular version of FileMaker Server, but clearly, things are moving in that direction for FileMaker Cloud too.

Authentication for Customer Functionality

There is more to consider — the functionality you develop for your customers is also going to involve different ways of authenticating. Providing just a username and password to log into a mail server, for instance, is on the way out. Here too, using OAuth is something that you, as a developer, will need to become familiar with. Here is a two-part set of blog articles that use the Microsoft Office 365 APIs as a guiding example. The first part of this series is dedicated entirely to the authentication options for this API, and it applies to other similar APIs as well.

Next Steps for Authentication in Your FileMaker Solution

Feel free to seek us out here or on the Claris Community Forum to ask questions on security in general and authentication in particular.

4 thoughts on “OneLogin for FileMaker User Authentication”

    1. No, it won’t.
      From a purely technical point of view it probably does, but with FM Cloud we don’t have access to the underlying config file to make the necessary changes.

  1. Hello,

    I am trying to create an OAUTH connection using OPENID Connect to my University. https://authentication.oit.duke.edu/manager/documentation

    I have the External IDP set up in Claris and what seems to be the correct registration on the university side. I am getting a message upon login that reads: This operation is not Supported Error.Oauth_SSP_Code: Unauthorized (Bad Credentials).
    Any ideas?

    1. If the Duke IdP supports OpenID Connect then it should work. The white papers we have include troubleshooting steps to make sure that each leg of the OAuth process produces the correct result; the most import one is the ability to inspect the JWT id_token to verify that it contains the pieces that FileMaker Server is looking for.
      Contact us directly if you need help going through that troubleshooting process.

Leave a Comment

Your email address will not be published. Required fields are marked *

We're celebrating 20 years! Read about our journey here.

Party horn and confetti
Scroll to Top