[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fHbsYs7ybP6ik6TAQoEBfKBxLdqwjdLQc_GiCAiuVsv4":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":25,"hasDownload":26,"fileName":27,"youtubeId":28,"clusterCrumb":29},"282","62D7DE7E-3C3C-3E4B-8236-6BD493B79956","7ED70569-3C8F-E044-A664-EACFBB2CB338","7D5B0EBD-0116-2746-99E4-A568A0AF2D3F","article","what-is-single-sign-on","What is single sign-on?","What single sign-on (SSO) actually is, how it works under the hood, and how business software like FileMaker apps can use it to cut password chaos and login risk.","Ask any employee how many passwords they juggle before lunch and you'll get a tired laugh. The CRM has one login. The ERP has another. The custom FileMaker app the warehouse team uses has a third — often with a password policy nobody remembers until it locks them out. Multiply that across dozens of systems and hundreds of employees, and you get help desk tickets, sticky notes with passwords on monitors, and IT managers who lose sleep over which ex-employee still has access to what.\n\nSingle sign-on (SSO) is the fix most companies reach for once this pain gets loud enough. This article explains exactly what SSO is, how it technically works, and what it takes to actually add it to business software — including custom-built systems like FileMaker apps that weren't born with it.\n\n## What is single sign-on, in plain terms?\n\nSingle sign-on is a login setup where a user authenticates once — usually against a central identity provider like Microsoft Entra ID (Azure AD), Google Workspace, or Okta — and that single login then grants access to multiple separate applications, without having to log in again for each one.\n\nConcretely: an employee opens their laptop in the morning and signs into Microsoft 365 once. From that point on, opening the company's CRM, the internal FileMaker order system, and the ERP dashboard all just work — no extra username, no extra password, no extra prompt. One identity, one login event, many applications trusting that same session.\n\nThat's the experience layer. Underneath it, SSO is really an identity and trust protocol problem, which is why it's almost always built on standards like SAML, OpenID Connect, or OAuth 2.0 rather than something proprietary. If you want the deeper mechanics of how identity tokens are issued, verified, and passed between systems, our [practical guide to identity and OAuth for business integrations](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fa-practical-guide-to-identity-and-oauth-for-business-integrations) covers that in detail — this article focuses specifically on the SSO layer built on top of that foundation.\n\n## How does SSO actually work under the hood?\n\nIt helps to walk through the real sequence of events, because \"one login for everything\" sounds like magic until you see the mechanics:\n\n1. **The user opens an application** (say, the FileMaker-based order management system).\n2. **The app checks: is there a valid session?** If not, instead of showing its own login form, it redirects the user to a central identity provider (IdP) — Entra ID, Okta, Google, etc.\n3. **The identity provider checks if the user is already authenticated** elsewhere in the browser\u002Fdevice session. If yes, it skips straight to step 5. If no, it asks for credentials once (password, plus MFA if configured).\n4. **The user authenticates** against the identity provider — not against the application itself. The application never sees or stores the password.\n5. **The identity provider issues a signed token** (a SAML assertion or an OpenID Connect\u002FOAuth token) confirming who the user is, and sends it back to the application.\n6. **The application verifies the token's signature** and, if valid, grants access — creating a local session so it doesn't need to re-check on every click.\n\nThe key detail people miss: the application never handles the password. It only ever handles a signed, time-limited token that says \"this identity provider vouches for this user.\" That's what makes SSO fundamentally different from just \"remembering\" a password with a browser autofill — it's a trust relationship between systems, not a shortcut for typing less.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F322?w=700&f=webp\" alt=\"one user, one login arrow into identity provider, tokens fanning out to three apps\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## Why do businesses actually adopt SSO — beyond convenience?\n\nConvenience is the visible reason. The real business drivers are usually these four:\n\n- **Security.** Every extra password is another thing that can be phished, reused across sites, or written on a sticky note. Centralizing authentication means MFA, conditional access policies, and login monitoring apply everywhere at once, not just on the systems IT remembered to configure.\n- **Offboarding speed.** When someone leaves the company, disabling their account in the identity provider instantly cuts access to every connected system — CRM, ERP, custom apps, file shares. Without SSO, an IT manager has to remember and manually revoke access system by system, and something always gets missed.\n- **Audit and compliance.** Frameworks like ISO 27001, NIS2, or customer security questionnaires increasingly expect centralized access control and logging. \"We can show exactly who logged into what, when\" is a much easier sentence to say with SSO than without it.\n- **Reduced help desk load.** Password reset requests are one of the most common (and most avoidable) IT support tickets. Fewer separate credentials means fewer forgotten ones.\n\n## Can a custom FileMaker application actually support SSO?\n\nYes — and this is where a lot of the confusion happens, because \"FileMaker doesn't have SSO built in like a big SaaS product does\" is only half true.\n\nFileMaker Server and FileMaker Cloud support OAuth 2.0 identity providers (Microsoft, Google, Amazon) natively as a login method for FileMaker Pro clients and WebDirect. That covers the classic desktop\u002Fbrowser FileMaker experience: a user opens the FileMaker file, gets redirected to sign in with their Microsoft account, and is in — no separate FileMaker credentials to manage.\n\nWhere it gets more involved is anything built *around* FileMaker rather than *in* FileMaker's native client:\n\n- **AI layers like Klai**, which sit on top of a FileMaker back end to power conversational or automated workflows, typically need their own identity handling — either passing through the same OAuth token FileMaker itself trusts, or maintaining a separate service-to-service credential that's scoped tightly enough not to become a security gap.\n- **Web form tools like FmBetterforms**, used to build public-facing or portal-style forms against FileMaker data, often run outside the standard FileMaker client entirely. If those forms are meant to be used by employees under the company's SSO policy (rather than by anonymous external users), that identity check has to be engineered deliberately — it doesn't come for free just because the underlying data lives in FileMaker.\n\nThe practical takeaway: SSO for a *simple* FileMaker file opened by internal staff is usually a configuration exercise. SSO for a *composite* system — FileMaker plus an AI layer plus a custom web portal plus maybe an ERP connector — is an integration design exercise. Each additional layer is another place that either trusts the same identity token or requires its own bridge to it.\n\n## What are the different flavors of SSO you'll run into?\n\n- **Enterprise SSO (federated SSO)** — the classic setup described above, using SAML or OpenID Connect against a corporate identity provider like Entra ID or Okta. This is what most B2B software integration projects mean by \"SSO.\"\n- **Social login** — \"Sign in with Google\u002FMicrosoft\u002FApple\" on consumer-facing sites. Technically similar (OAuth\u002FOpenID Connect under the hood) but usually not tied to corporate access policy.\n- **Web SSO vs. desktop SSO** — browser-based SSO (redirect flows) is straightforward; making a native desktop client like FileMaker Pro participate in the same session requires the app to support OAuth natively, which FileMaker does from FileMaker 19+ onward.\n- **SSO vs. password vaulting** — tools that auto-fill saved passwords into multiple login forms *look* like SSO to the end user but are not the same thing technically: the app still has its own separate password, just typed automatically. It gives none of the offboarding or centralized-audit benefits of true SSO.\n\n## What should you check before rolling out SSO on a custom system?\n\nA short pre-flight checklist we run through with clients before wiring SSO into a custom or hybrid FileMaker environment:\n\n- [ ] Which identity provider does the company already standardize on (Entra ID, Google Workspace, Okta, other)?\n- [ ] Does every layer of the system (FileMaker client, any web portals, any AI or automation layer) need to participate in SSO, or only some?\n- [ ] Is there a fallback login path for service accounts, integrations, or scripted processes that can't go through an interactive browser redirect?\n- [ ] How will group membership or role in the identity provider map to permissions inside the application (privilege sets in FileMaker, roles in the ERP, etc.)?\n- [ ] What happens the moment an account is disabled centrally — is access to every connected layer actually cut immediately, or does something cache a session longer than expected?\n- [ ] Is multi-factor authentication (MFA) enforced at the identity provider level, so it automatically covers every connected app?\n\n## FAQ\n\n**Is SSO the same as OAuth?**\nNo. OAuth is one of the underlying protocols (originally for authorization, later adapted for authentication via OpenID Connect) that SSO is often *built on*. SSO is the user-facing outcome — one login for many apps — not the protocol itself.\n\n**Does SSO make a system more or less secure?**\nGenerally more secure, because it centralizes MFA, monitoring, and offboarding — but it also means the identity provider becomes a single point of failure. If that account is compromised, the blast radius is every connected system, which is exactly why MFA on the identity provider is non-negotiable when SSO is in place.\n\n**Can SSO work with systems that aren't in the cloud?**\nYes. On-premises FileMaker Server deployments can still authenticate against cloud identity providers over OAuth, and on-prem identity providers (like an on-site Active Directory Federation Services setup) can serve SAML-based SSO to both cloud and local applications.\n\n**Do small companies need SSO, or is it only for large enterprises?**\nAny company managing more than a handful of business applications benefits from it — the offboarding and password-reset savings alone often justify it well before headcount reaches \"enterprise\" scale.\n\n---\n\nGetting SSO right on a mix of standard software and custom-built systems is rarely a checkbox — it's an integration design question about which layers trust which tokens, and what happens the moment someone leaves the company. If your FileMaker application, AI layer, or connected web portal wasn't built with that in mind from day one, Loggix can help map out where SSO fits, build the missing bridges through API integrations, or extend the underlying FileMaker solution so identity and access control work the way your IT team actually needs them to.","\u003Cp>Ask any employee how many passwords they juggle before lunch and you'll get a tired laugh. The CRM has one login. The ERP has another. The custom FileMaker app the warehouse team uses has a third — often with a password policy nobody remembers until it locks them out. Multiply that across dozens of systems and hundreds of employees, and you get help desk tickets, sticky notes with passwords on monitors, and IT managers who lose sleep over which ex-employee still has access to what.\u003C\u002Fp>\n\u003Cp>Single sign-on (SSO) is the fix most companies reach for once this pain gets loud enough. This article explains exactly what SSO is, how it technically works, and what it takes to actually add it to business software — including custom-built systems like FileMaker apps that weren't born with it.\u003C\u002Fp>\n\u003Ch2>What is single sign-on, in plain terms?\u003C\u002Fh2>\n\u003Cp>Single sign-on is a login setup where a user authenticates once — usually against a central identity provider like Microsoft Entra ID (Azure AD), Google Workspace, or Okta — and that single login then grants access to multiple separate applications, without having to log in again for each one.\u003C\u002Fp>\n\u003Cp>Concretely: an employee opens their laptop in the morning and signs into Microsoft 365 once. From that point on, opening the company's CRM, the internal FileMaker order system, and the ERP dashboard all just work — no extra username, no extra password, no extra prompt. One identity, one login event, many applications trusting that same session.\u003C\u002Fp>\n\u003Cp>That's the experience layer. Underneath it, SSO is really an identity and trust protocol problem, which is why it's almost always built on standards like SAML, OpenID Connect, or OAuth 2.0 rather than something proprietary. If you want the deeper mechanics of how identity tokens are issued, verified, and passed between systems, our \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fa-practical-guide-to-identity-and-oauth-for-business-integrations\">practical guide to identity and OAuth for business integrations\u003C\u002Fa> covers that in detail — this article focuses specifically on the SSO layer built on top of that foundation.\u003C\u002Fp>\n\u003Ch2>How does SSO actually work under the hood?\u003C\u002Fh2>\n\u003Cp>It helps to walk through the real sequence of events, because "one login for everything" sounds like magic until you see the mechanics:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>The user opens an application\u003C\u002Fstrong> (say, the FileMaker-based order management system).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The app checks: is there a valid session?\u003C\u002Fstrong> If not, instead of showing its own login form, it redirects the user to a central identity provider (IdP) — Entra ID, Okta, Google, etc.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The identity provider checks if the user is already authenticated\u003C\u002Fstrong> elsewhere in the browser\u002Fdevice session. If yes, it skips straight to step 5. If no, it asks for credentials once (password, plus MFA if configured).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The user authenticates\u003C\u002Fstrong> against the identity provider — not against the application itself. The application never sees or stores the password.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The identity provider issues a signed token\u003C\u002Fstrong> (a SAML assertion or an OpenID Connect\u002FOAuth token) confirming who the user is, and sends it back to the application.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>The application verifies the token's signature\u003C\u002Fstrong> and, if valid, grants access — creating a local session so it doesn't need to re-check on every click.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>The key detail people miss: the application never handles the password. It only ever handles a signed, time-limited token that says "this identity provider vouches for this user." That's what makes SSO fundamentally different from just "remembering" a password with a browser autofill — it's a trust relationship between systems, not a shortcut for typing less.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F322?w=700&f=webp\" alt=\"one user, one login arrow into identity provider, tokens fanning out to three apps\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>Why do businesses actually adopt SSO — beyond convenience?\u003C\u002Fh2>\n\u003Cp>Convenience is the visible reason. The real business drivers are usually these four:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Security.\u003C\u002Fstrong> Every extra password is another thing that can be phished, reused across sites, or written on a sticky note. Centralizing authentication means MFA, conditional access policies, and login monitoring apply everywhere at once, not just on the systems IT remembered to configure.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Offboarding speed.\u003C\u002Fstrong> When someone leaves the company, disabling their account in the identity provider instantly cuts access to every connected system — CRM, ERP, custom apps, file shares. Without SSO, an IT manager has to remember and manually revoke access system by system, and something always gets missed.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Audit and compliance.\u003C\u002Fstrong> Frameworks like ISO 27001, NIS2, or customer security questionnaires increasingly expect centralized access control and logging. "We can show exactly who logged into what, when" is a much easier sentence to say with SSO than without it.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Reduced help desk load.\u003C\u002Fstrong> Password reset requests are one of the most common (and most avoidable) IT support tickets. Fewer separate credentials means fewer forgotten ones.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Can a custom FileMaker application actually support SSO?\u003C\u002Fh2>\n\u003Cp>Yes — and this is where a lot of the confusion happens, because "FileMaker doesn't have SSO built in like a big SaaS product does" is only half true.\u003C\u002Fp>\n\u003Cp>FileMaker Server and FileMaker Cloud support OAuth 2.0 identity providers (Microsoft, Google, Amazon) natively as a login method for FileMaker Pro clients and WebDirect. That covers the classic desktop\u002Fbrowser FileMaker experience: a user opens the FileMaker file, gets redirected to sign in with their Microsoft account, and is in — no separate FileMaker credentials to manage.\u003C\u002Fp>\n\u003Cp>Where it gets more involved is anything built \u003Cem>around\u003C\u002Fem> FileMaker rather than \u003Cem>in\u003C\u002Fem> FileMaker's native client:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>AI layers like Klai\u003C\u002Fstrong>, which sit on top of a FileMaker back end to power conversational or automated workflows, typically need their own identity handling — either passing through the same OAuth token FileMaker itself trusts, or maintaining a separate service-to-service credential that's scoped tightly enough not to become a security gap.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Web form tools like FmBetterforms\u003C\u002Fstrong>, used to build public-facing or portal-style forms against FileMaker data, often run outside the standard FileMaker client entirely. If those forms are meant to be used by employees under the company's SSO policy (rather than by anonymous external users), that identity check has to be engineered deliberately — it doesn't come for free just because the underlying data lives in FileMaker.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The practical takeaway: SSO for a \u003Cem>simple\u003C\u002Fem> FileMaker file opened by internal staff is usually a configuration exercise. SSO for a \u003Cem>composite\u003C\u002Fem> system — FileMaker plus an AI layer plus a custom web portal plus maybe an ERP connector — is an integration design exercise. Each additional layer is another place that either trusts the same identity token or requires its own bridge to it.\u003C\u002Fp>\n\u003Ch2>What are the different flavors of SSO you'll run into?\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Enterprise SSO (federated SSO)\u003C\u002Fstrong> — the classic setup described above, using SAML or OpenID Connect against a corporate identity provider like Entra ID or Okta. This is what most B2B software integration projects mean by "SSO."\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Social login\u003C\u002Fstrong> — "Sign in with Google\u002FMicrosoft\u002FApple" on consumer-facing sites. Technically similar (OAuth\u002FOpenID Connect under the hood) but usually not tied to corporate access policy.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Web SSO vs. desktop SSO\u003C\u002Fstrong> — browser-based SSO (redirect flows) is straightforward; making a native desktop client like FileMaker Pro participate in the same session requires the app to support OAuth natively, which FileMaker does from FileMaker 19+ onward.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>SSO vs. password vaulting\u003C\u002Fstrong> — tools that auto-fill saved passwords into multiple login forms \u003Cem>look\u003C\u002Fem> like SSO to the end user but are not the same thing technically: the app still has its own separate password, just typed automatically. It gives none of the offboarding or centralized-audit benefits of true SSO.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>What should you check before rolling out SSO on a custom system?\u003C\u002Fh2>\n\u003Cp>A short pre-flight checklist we run through with clients before wiring SSO into a custom or hybrid FileMaker environment:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Which identity provider does the company already standardize on (Entra ID, Google Workspace, Okta, other)?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Does every layer of the system (FileMaker client, any web portals, any AI or automation layer) need to participate in SSO, or only some?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is there a fallback login path for service accounts, integrations, or scripted processes that can't go through an interactive browser redirect?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> How will group membership or role in the identity provider map to permissions inside the application (privilege sets in FileMaker, roles in the ERP, etc.)?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> What happens the moment an account is disabled centrally — is access to every connected layer actually cut immediately, or does something cache a session longer than expected?\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Is multi-factor authentication (MFA) enforced at the identity provider level, so it automatically covers every connected app?\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Is SSO the same as OAuth?\u003C\u002Fstrong>\nNo. OAuth is one of the underlying protocols (originally for authorization, later adapted for authentication via OpenID Connect) that SSO is often \u003Cem>built on\u003C\u002Fem>. SSO is the user-facing outcome — one login for many apps — not the protocol itself.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Does SSO make a system more or less secure?\u003C\u002Fstrong>\nGenerally more secure, because it centralizes MFA, monitoring, and offboarding — but it also means the identity provider becomes a single point of failure. If that account is compromised, the blast radius is every connected system, which is exactly why MFA on the identity provider is non-negotiable when SSO is in place.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Can SSO work with systems that aren't in the cloud?\u003C\u002Fstrong>\nYes. On-premises FileMaker Server deployments can still authenticate against cloud identity providers over OAuth, and on-prem identity providers (like an on-site Active Directory Federation Services setup) can serve SAML-based SSO to both cloud and local applications.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Do small companies need SSO, or is it only for large enterprises?\u003C\u002Fstrong>\nAny company managing more than a handful of business applications benefits from it — the offboarding and password-reset savings alone often justify it well before headcount reaches "enterprise" scale.\u003C\u002Fp>\n\u003Chr>\n\u003Cp>Getting SSO right on a mix of standard software and custom-built systems is rarely a checkbox — it's an integration design question about which layers trust which tokens, and what happens the moment someone leaves the company. If your FileMaker application, AI layer, or connected web portal wasn't built with that in mind from day one, Loggix can help map out where SSO fits, build the missing bridges through API integrations, or extend the underlying FileMaker solution so identity and access control work the way your IT team actually needs them to.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901671000,[19,20,21,22,23,24],"single sign-on","SSO","identity and access management","OAuth","FileMaker security","business software authentication","\u002Fapi\u002Fknowledge\u002Fimage\u002F282\u002F?v=2ab548dfee5d",false,"",null,{"title":30,"slug":31},"A practical guide to identity and OAuth for business integrations","a-practical-guide-to-identity-and-oauth-for-business-integrations"]