# SSO-opties voor Google Workspace: een overzicht

De **SSO-opties voor Google Workspace** bepalen hoe je gebruikers veilig en gemakkelijk inloggen op al hun apps. In dit artikel zie je de drie hoofdmodellen, hoe SAML en OIDC werken en hoe je de juiste opzet kiest voor jouw organisatie.

[[TOC]]

## Wat is SSO en waarom is het belangrijk

Single Sign-On, kortweg SSO, laat een gebruiker met een set inloggegevens toegang krijgen tot meerdere applicaties. In plaats van voor elke app een apart wachtwoord betekent SSO een keer inloggen en daarna naadloos doorwerken. Dat is gemakkelijker voor gebruikers en veiliger voor de organisatie.

De beveiligingswinst is groot. Met SSO beheer je toegang centraal: zet je een account uit, dan vervalt de toegang tot alle gekoppelde apps tegelijk. Je dwingt overal hetzelfde sterke wachtwoordbeleid en dezelfde [[security-mfa|meervoudige authenticatie]] af, zonder dat gebruikers tientallen wachtwoorden hoeven te onthouden.

:::info title="SSO en MFA werken samen"
SSO vervangt geen MFA, het versterkt het. Door MFA op je centrale inlogpunt af te dwingen, bescherm je in een klap alle gekoppelde apps. Combineer SSO altijd met sterke meervoudige authenticatie, en overweeg passkeys, die Google inmiddels als standaard inlogmethode stimuleert.
:::

## Optie 1: Google als identity provider

In dit model is Google Workspace je centrale identiteitsbron. Gebruikers loggen in met hun Google-account en Google verzorgt de authenticatie voor andere apps via SAML of OIDC. Dit is logisch als Workspace de kern van je organisatie vormt. Google biedt vooraf ingerichte koppelingen voor honderden bekende clouddiensten, en daarnaast kun je elke andere SAML-app handmatig toevoegen.

:::howto title="Een app koppelen met Google als provider"
1. Open de Admin-console en ga naar **Apps**, daarna **Webapps en mobiele apps**.
2. Kies **App toevoegen** en selecteer een app uit de catalogus, of voeg met **Aangepaste SAML-app** je eigen app toe.
3. Wissel de metadata uit tussen Google en de app, zoals de certificaten, de entity-ID en de ACS-URL.
4. Wijs toe welke organisatie-eenheden of groepen de app mogen gebruiken.
5. Test de inlog met een proefaccount voordat je breed uitrolt.
6. Zet de app op **AAN** voor de rest van de organisatie zodra de test slaagt.
:::

## Optie 2: externe identity provider

Heb je al een centrale identiteitsprovider zoals Microsoft Entra ID of Okta, dan draai je het om. Die provider wordt je bron van waarheid en Google Workspace wordt een aangesloten dienst. Gebruikers loggen in bij de externe provider en krijgen daarmee toegang tot Workspace.

Dit stel je in via de Admin-console onder **Beveiliging**, dan **Authenticatie**, dan **SSO met externe IdP**. Daar voeg je een SAML- of OIDC-profiel toe en upload je de metadata of vul je de gegevens van je provider in.

Welke provider je leidend maakt, hangt af van waar je zwaartepunt ligt:

| Situatie | Aanbevolen opzet |
| --- | --- |
| Workspace is je hoofdomgeving | Google als identity provider |
| Je gebruikt al breed Microsoft Entra of Okta | Externe provider leidend, Workspace als aangesloten dienst |

Dit model past bij organisaties die meerdere clouddiensten gebruiken en de identiteiten op een plek willen beheren. Vaak combineer je dit met [[workspace-scim-auto|SCIM-provisioning]] zodat accounts automatisch worden aangemaakt, bijgewerkt en verwijderd.

## Optie 3: hybride opzet

Sommige organisaties combineren beide. Google handelt de authenticatie voor bepaalde apps af, terwijl een externe provider andere delen beheert. Sinds Google meerdere SSO-profielen ondersteunt, kun je verschillende providers toewijzen aan verschillende organisatie-eenheden of groepen. Zo kan bijvoorbeeld de ene afdeling via Entra inloggen en de andere via Google, binnen dezelfde organisatie. Dat geeft flexibiliteit, maar vraagt zorgvuldige inrichting om gaten te voorkomen.

:::warn title="Hybride opzet vraagt om strak overzicht"
Een hybride SSO-opzet vergroot de kans op configuratiefouten en blinde vlekken in je toegangsbeheer. Documenteer precies welke app en welke organisatie-eenheid via welke provider loopt, en controleer regelmatig of er geen accounts buiten je centrale beheer vallen.
:::

## SSO uitrollen zonder gedoe

Een SSO-project mislukt zelden op de techniek en vaak op de uitrol. Gebruikers die plots anders moeten inloggen, raken in de war als je het niet goed begeleidt. Plan de uitrol daarom in fasen en communiceer ruim van tevoren wat er verandert. Een korte handleiding met schermafbeeldingen voorkomt een golf aan supportvragen op de dag dat je overschakelt.

Begin met een kleine pilotgroep van technisch onderlegde collega's die fouten kunnen opvangen en feedback geven. Loop met hen het volledige inlogproces door, inclusief de minder voorkomende situaties zoals inloggen op mobiel of vanaf een nieuw apparaat. Pas de configuratie aan op basis van wat je leert, en breid pas daarna uit naar grotere groepen. Deze gefaseerde aanpak houdt de impact beheersbaar als er iets niet klopt.

Vergeet ook de noodtoegang niet. Als je SSO-provider onverhoopt uitvalt, mag dat niet betekenen dat niemand er meer in kan. Richt een noodprocedure in met een beperkt aantal beheerdersaccounts die buiten de normale SSO-flow om kunnen inloggen, goed beveiligd en streng gemonitord. Zo houd je altijd een achterdeur open voor het geval je centrale inlogpunt het laat afweten, zonder dat die achterdeur zelf een zwakke plek wordt in je beveiliging.

## De juiste opzet kiezen

Vormt Workspace de kern van je organisatie, dan is Google als provider de eenvoudigste route. Gebruik je al breed een externe provider, maak die dan leidend en sluit Workspace aan. Combineer SSO altijd met MFA en, waar mogelijk, met [[workspace-scim-auto|automatische provisioning]] voor een sluitend toegangsbeheer.

:::faq
### Heb ik een bepaalde Workspace-editie nodig voor SSO?
Basale SAML- en OIDC-SSO is beschikbaar in vrijwel alle zakelijke edities. Geavanceerde functies zoals contextgevoelige toegang vereisen hogere edities. Controleer je editie in de Admin-console.

### Wat is het verschil tussen SAML en OIDC?
SAML en OIDC zijn beide standaarden voor SSO. SAML is ouder en veel gebruikt voor zakelijke apps, OIDC is moderner en gebouwd op OAuth2. Veel apps ondersteunen beide, en Google Workspace kan met allebei overweg.

### Kan ik meerdere identity providers tegelijk gebruiken?
Ja. Google ondersteunt meerdere SSO-profielen die je per organisatie-eenheid of groep toewijst. Zo kunnen verschillende afdelingen via verschillende providers inloggen binnen dezelfde organisatie.

### Wat gebeurt er als mijn identity provider uitvalt?
Als je centrale provider onbereikbaar is, kunnen gebruikers niet inloggen op gekoppelde apps. Plan daarom voor hoge beschikbaarheid en houd een noodtoegangsprocedure met losse beheerdersaccounts achter de hand.

### Kan ik SSO geleidelijk uitrollen?
Ja, je kunt SSO per app en per groep inschakelen. Begin met een testgroep en een paar apps, en breid uit zodra je zeker weet dat alles werkt.

### Waar stel ik een externe provider in de Admin-console in?
Ga naar Beveiliging, dan Authenticatie, dan SSO met externe IdP. Daar voeg je een SAML- of OIDC-profiel toe met de metadata van je provider en wijs je het toe aan de juiste organisatie-eenheden of groepen.
:::