Wat is single sign-on?

Vraag een willekeurige medewerker hoeveel wachtwoorden ze voor het middageten moeten onthouden en je krijgt een vermoeid lachje. De CRM heeft één logingegevens. De ERP heeft een ander. De aangepaste FileMaker-app die het magazijnteam gebruikt heeft een derde — vaak met een wachtwoordbeleid dat niemand zich herinnert totdat ze buitengesloten worden. Vermenigvuldig dat met tientallen systemen en honderden medewerkers, en je hebt helpdesk-tickets, plaknotities met wachtwoorden op monitors en IT-managers die nachten wakker liggen over welke ex-medewerker nog steeds toegang heeft tot wat.

Single sign-on (SSO) is de oplossing waar de meeste bedrijven naar grijpen zodra deze pijn luid genoeg wordt gehoord. Dit artikel legt uit wat SSO precies is, hoe het technisch werkt en wat het kost om het echt toe te voegen aan bedrijfssoftware — inclusief aangepaste systemen zoals FileMaker-apps die er niet mee zijn geboren.

Wat is single sign-on, in gewone taal?

Single sign-on is een loginopstelling waarbij een gebruiker zich eenmaal authenticeert — meestal tegen een centraal identiteitsprovider zoals Microsoft Entra ID (Azure AD), Google Workspace of Okta — en die enkele login vervolgens toegang verleent tot meerdere afzonderlijke applicaties, zonder dat je je voor elk ervan opnieuw hoeft aan te melden.

Concreet: een medewerker start zijn laptop 's ochtends op en meldt zich eenmaal aan bij Microsoft 365. Vanaf dat moment werken het openen van de bedrijfs-CRM, het interne FileMaker-ordersysteem en het ERP-dashboard gewoon — geen extra gebruikersnaam, geen extra wachtwoord, geen extra prompt. Één identiteit, één aanmeldingsgebeurtenis, veel applicaties die dezelfde sessie vertrouwen.

Dat is de ervaringlaag. Eronder is SSO eigenlijk een identiteits- en vertrouwensprobleem, daarom is het bijna altijd gebaseerd op standaarden zoals SAML, OpenID Connect of OAuth 2.0 in plaats van iets eigenstandigs. Als je meer over de diepere mechanica wilt weten van hoe identiteitstokens worden uitgegeven, geverifieerd en doorgegeven tussen systemen, lees onze praktische gids voor identiteit en OAuth voor zakelijke integraties — dit artikel richt zich specifiek op de SSO-laag die daarbovenop is gebouwd.

Hoe werkt SSO eigenlijk onder de motorkap?

Het helpt om de echte opeenvolging van gebeurtenissen door te nemen, omdat "één login voor alles" als magie klinkt totdat je de mechanica ziet:

1. De gebruiker opent een applicatie (bijvoorbeeld het FileMaker-gebaseerde ordermanagementsysteem).
2. De app controleert: is er een geldige sessie? Zo niet, dan toont het niet zijn eigen aanmeldingsformulier, maar stuurt het de gebruiker door naar een centraal identiteitsprovider (IdP) — Entra ID, Okta, Google, etc.
3. De identiteitsprovider controleert of de gebruiker al geverifieerd is elders in de browser/devicesessie. Zo ja, dan slaat het direct stap 5 over. Zo niet, dan vraagt het eenmaal om inloggegevens (wachtwoord, plus MFA als geconfigureerd).
4. De gebruiker authenticeert zich tegen de identiteitsprovider — niet tegen de applicatie zelf. De applicatie ziet het wachtwoord nooit en slaat het niet op.
5. De identiteitsprovider geeft een ondertekend token uit (een SAML-bewering of een OpenID Connect/OAuth-token) dat bevestigt wie de gebruiker is, en stuurt het terug naar de applicatie.
6. De applicatie verifieert de handtekening van het token en verleent, als deze geldig is, toegang — door een lokale sessie te creëren zodat het niet op elke klik hoeft te controleren.

Het sleuteldetail dat mensen missen: de applicatie handelt het wachtwoord nooit af. Het handelt alleen een ondertekend, tijdsbeperkt token af dat zegt "deze identiteitsprovider garandeert voor deze gebruiker." Dat is wat SSO fundamenteel anders maakt dan alleen een wachtwoord "onthouden" met browserautofill — het is een vertrouwensrelatie tussen systemen, niet een snelkoppeling voor minder typen.

Waarom nemen bedrijven SSO eigenlijk aan — verder dan gemak?

Gemak is de zichtbare reden. De echte bedrijfsdrijfveren zijn meestal deze vier:

• Beveiliging. Elk extra wachtwoord is nog iets dat kan worden gephished, opnieuw gebruikt over sites, of op een plaknotitie kan worden geschreven. Het centraliseren van authenticatie betekent dat MFA, beleid voor voorwaardelijke toegang en aanmeldingsbewaking overal tegelijk van toepassing zijn, niet alleen op de systemen waarvan IT zich herinnert deze in te stellen.
• Snelheid bij uitdiensttreding. Wanneer iemand het bedrijf verlaat, ontkoppelt het uitschakelen van hun account in de identiteitsprovider onmiddellijk de toegang tot elk verbonden systeem — CRM, ERP, aangepaste apps, bestandsshares. Zonder SSO moet een IT-manager de toegang handmatig systeem voor systeem intrekken en iets gaat altijd verloren.
• Audit en compliance. Kaders zoals ISO 27001, NIS2 of klantenveiligingsvragenlijsten verwachten steeds meer centrale toegangscontrole en logging. "We kunnen exact zien wie wanneer wat heeft geopend" is een veel gemakkelijkere zin om te zeggen met SSO dan zonder.
• Verminderde helpdesk-belasting. Wachtwoordresetstrategie is een van de meest voorkomende (en meest te vermijden) IT-ondersteuningstickets. Minder afzonderlijke inloggegevens betekent minder vergeten inloggegevens.

Kan een aangepaste FileMaker-applicatie SSO echt ondersteunen?

Ja — en hier gebeurt veel van de verwarring, omdat "FileMaker heeft geen SSO ingebouwd zoals een groot SaaS-product" slechts half waar is.

FileMaker Server en FileMaker Cloud ondersteunen OAuth 2.0-identiteitsproviders (Microsoft, Google, Amazon) natively als een aanmeldingsmethode voor FileMaker Pro-clients en WebDirect. Dit dekt de klassieke desktop-/browserFileMaker-ervaring: een gebruiker opent het FileMaker-bestand, wordt doorgestuurd om zich aan te melden met zijn Microsoft-account, en is erin — geen aparte FileMaker-inloggegevens om te beheren.

Het wordt ingewikkelder met alles wat rond FileMaker is gebouwd in plaats van in FileMakers native client:

• AI-lagen zoals Klai, die bovenop een FileMaker-backend zitten om conversatie- of geautomatiseerde workflows mogelijk te maken, hebben meestal hun eigen identiteitsafhandeling nodig — ofwel door hetzelfde OAuth-token door te geven dat FileMaker zelf vertrouwt, ofwel door een aparte service-to-service-referentie te onderhouden die zo nauw gericht is dat het geen veiligheidsgat wordt.
• Webformuliertools zoals FmBetterforms, gebruikt om publiek gerichte of portalstijl-formulieren tegen FileMaker-gegevens te bouwen, draaien vaak buiten de standaard FileMaker-client geheel. Als die formulieren door medewerkers onder het SSO-beleid van het bedrijf moeten worden gebruikt (in plaats van door anonieme externe gebruikers), moet die identiteitscontrole opzettelijk worden uitgevoerd — het komt niet gratis alleen omdat de onderliggende gegevens in FileMaker staan.

De praktische conclusie: SSO voor een eenvoudig FileMaker-bestand dat door intern personeel wordt geopend, is meestal een configuratiehandeling. SSO voor een samengesteld systeem — FileMaker plus een AI-laag plus een aangepast webportaal plus misschien een ERP-connector — is een integratieontwerp-oefening. Elke aanvullende laag is nog een plaats die hetzelfde identiteitstoken vertrouwt of een brug ernaar toe nodig heeft.

Wat zijn de verschillende soorten SSO die je tegenkomt?

• Enterprise SSO (gefedereerde SSO) — de klassieke opstelling die hierboven wordt beschreven, met behulp van SAML of OpenID Connect tegen een bedrijfsidentiteitsprovider zoals Entra ID of Okta. Dit is wat meeste B2B-softwareintegratieprojecten bedoelen met "SSO".
• Social login — "Aanmelden met Google/Microsoft/Apple" op voor consumenten bedoelde sites. Technisch vergelijkbaar (OAuth/OpenID Connect onder de motorkap) maar meestal niet gebonden aan bedrijfstoegangsbeleid.
• Web-SSO vs. desktop-SSO — browsergebaseerde SSO (omleidingsstromen) is eenvoudig; een native desktopapplicatie als FileMaker Pro dezelfde sessie laten gebruiken vereist dat de app OAuth natively ondersteunt, wat FileMaker doet vanaf FileMaker 19+.
• SSO vs. wachtwoordkluis — tools die opgeslagen wachtwoorden automatisch invullen in meerdere aanmeldingsformulieren zien er voor de eindgebruiker uit als SSO, maar zijn technisch niet hetzelfde: de app heeft nog steeds zijn eigen aparte wachtwoord, alleen automatisch ingetypt. Het geeft geen van de voordelen van echte SSO op het gebied van uitdiensttreding of gecentraliseerde audit.

Wat moet je controleren voordat je SSO op een aangepast systeem uitrolt?

Een korte pre-vluchtchecklist die we met klanten doorlopen voordat we SSO in een aangepaste of hybride FileMaker-omgeving gaan draad:

• Welke identiteitsprovider past het bedrijf al standaard toe (Entra ID, Google Workspace, Okta, ander)?
• Moet elke laag van het systeem (FileMaker-client, eventuele webportalen, AI- of automatiseringslaag) in SSO deelnemen, of slechts enkele?
• Is er een terugvalloginpad voor serviceaccounts, integraties of scriptgebruiken die niet door een interactieve browseromleidingkan gaan?
• Hoe wordt groepslidmaatschap of rol in de identiteitsprovider toegewezen aan machtigingen in de applicatie (privilegesets in FileMaker, rollen in de ERP, enz.)?
• Wat gebeurt op het moment dat een account centraal wordt uitgeschakeld — wordt de toegang tot elke verbonden laag werkelijk onmiddellijk afgesneden, of cacht iets een sessie langer dan verwacht?
• Wordt multi-factor authentication (MFA) op het identiteitsprovider-niveau afgedwongen, zodat het automatisch elk verbonden app dekt?

Veelgestelde vragen

Is SSO hetzelfde als OAuth? Nee. OAuth is een van de onderliggende protocollen (oorspronkelijk voor autorisatie, later aangepast voor authenticatie via OpenID Connect) waarop SSO vaak is gebouwd. SSO is het aan de gebruiker gericht resultaat — één login voor veel apps — niet het protocol zelf.

Maakt SSO een systeem veiliger of minder veilig? Over het algemeen veiliger, omdat het MFA, monitoring en uitdiensttreding centraliseert — maar het betekent ook dat de identiteitsprovider een enkel foutpunt wordt. Als dat account wordt gecompromitteerd, is het blastradius elk verbonden systeem, wat precies waarom MFA op de identiteitsprovider niet ter discussie staat wanneer SSO aanwezig is.

Kan SSO werken met systemen die niet in de cloud zijn? Ja. Implementaties van FileMaker Server on-premises kunnen nog steeds authentificeren tegen identiteitsproviders in de cloud via OAuth, en on-premises identiteitsproviders (zoals een on-site Active Directory Federation Services-instelling) kunnen SAML-gebaseerde SSO leveren aan zowel cloud- als lokale applicaties.

Hebben kleine bedrijven SSO nodig, of is het alleen voor grote ondernemingen? Elk bedrijf dat meer dan een handvol zakelijke applicaties beheert, profiteert ervan — de besparing op uitdiensttreding en wachtwoordreset alleen rechtvaardigen het vaak al voordat het personeelsbestand op "enterprise"-schaal bereikt.

---

SSO goed krijgen op een mix van standaardsoftware en aangepaste systemen is zelden een checkbox — het is een integratieontwerp vraag over welke lagen welke tokens vertrouwen en wat gebeurt op het moment dat iemand het bedrijf verlaat. Als uw FileMaker-applicatie, AI-laag of verbonden webportaal niet van dag één met dit in gedachten is gebouwd, kan Loggix helpen uitzoeken waar SSO past, de ontbrekende bruggen via API-integraties bouwen, of de onderliggende FileMaker-oplossing uitbreiden zodat identiteit en toegangscontrole werken zoals uw IT-team ze werkelijk nodig heeft.