# Firebase koppelen aan Google Workspace

[[TOC]]

Veel organisaties bouwen interne tools waarvoor gebruikers met hun Workspace-account moeten inloggen en die vervolgens Workspace-data tonen of bewerken. Firebase is hiervoor een prettige basis: het regelt authenticatie, hosting en serverless logica, en sluit naadloos aan op de identiteitsdiensten van Google. In dit artikel verbind je Firebase stap voor stap met Workspace, met de nadruk op veilige, server-side gecontroleerde toegang.

## Inloggen met een Workspace-account

Firebase Authentication ondersteunt de Google-provider standaard. Workspace-accounts zijn Google-accounts, dus inloggen werkt direct. Met de `hd`-parameter stuur je de inlogervaring naar jouw organisatiedomein.

```javascript
import { GoogleAuthProvider, signInWithPopup, getAuth } from 'firebase/auth';

const provider = new GoogleAuthProvider();
provider.setCustomParameters({ hd: 'jouwdomein.nl' });
const auth = getAuth();
const resultaat = await signInWithPopup(auth, provider);
```

:::warn title="De hd-parameter is geen beveiliging"
De `hd`-parameter stuurt de inlogervaring naar jouw domein, maar is geen beveiliging op zichzelf. Een kwaadwillende kan die parameter aan de clientkant omzeilen. Verifieer daarom altijd server-side dat de gebruiker echt bij jouw organisatie hoort. Controleer bij voorkeur de `hd`-claim in het ID-token, want die geeft aan dat het account door jouw Workspace-domein wordt beheerd. Een controle op alleen het e-mailachtervoegsel is zwakker. Vertrouw nooit uitsluitend de client.
:::

## Tokens server-side verifieren

In je backend gebruik je de Firebase Admin SDK om het ID-token te valideren en de domeinclaim te controleren.

:::howto title="Veilige tokencontrole in vijf stappen"
1. Stuur het Firebase ID-token mee bij elke beveiligde request, in de `Authorization`-header.
2. Verifieer het token server-side met `admin.auth().verifyIdToken()`.
3. Controleer de `hd`-claim, en eventueel het e-mailadres, tegen jouw domein.
4. Controleer de gebruiker tegen een allowlist van toegestane accounts.
5. Verleen pas daarna toegang tot de gevraagde resource.
:::

```javascript
const decoded = await admin.auth().verifyIdToken(idToken);
if (decoded.hd !== 'jouwdomein.nl') {
  throw new Error('Toegang geweigerd');
}
```

:::tip title="Combineer domeincontrole met een allowlist"
Combineer de domeincontrole met een expliciete allowlist in je database. Zo bepaal je per gebruiker of die de app mag gebruiken, ook binnen je eigen domein. Dat geeft je fijnmazige controle zonder dat je de hele Workspace-admin hoeft aan te raken.
:::

## Workspace-data benaderen

Het Firebase-token bewijst wie de gebruiker is, maar geeft op zichzelf geen toegang tot Workspace-API's. Daarvoor heb je aparte autorisatie nodig. Welke aanpak je kiest, hangt af van wiens data je benadert:

| Doel | Aanpak |
| --- | --- |
| Eigen data van de ingelogde gebruiker benaderen | Vraag bij de login de juiste OAuth-scopes en gebruik het access token van die gebruiker. |
| Organisatiebrede data server-side benaderen | Gebruik een service account met domain-wide delegation in je Cloud Function. |

:::info title="Domain-wide delegation vereist een admin-actie"
Domain-wide delegation moet je eenmalig instellen in de Google Admin-console: je koppelt de client-ID van het service account aan de gewenste OAuth-scopes. Houd die scopes zo smal mogelijk; geef alleen toegang tot wat de app echt nodig heeft.
:::

## Cloud Functions for Firebase

De serverless functies van Firebase zijn de plek voor je backend-logica. Daar verifieer je tokens en roep je Workspace-API's aan met een service-identiteit. Op Google Cloud heb je daarvoor geen sleutelbestand nodig: de functie draait al onder een service account.

De flow ziet er zo uit:

1. De client logt in via Firebase Auth en krijgt een ID-token.
2. De client roept een Cloud Function aan en stuurt dat token mee.
3. De functie verifieert het token en de `hd`-domeinclaim.
4. De functie roept de gewenste Workspace-API aan met een service account met domain-wide delegation.
5. Het resultaat gaat terug naar de client.

:::warn title="Bewaar tokens en secrets nooit in de client"
Access tokens, refresh tokens en service-account-credentials horen niet thuis in de browser of de app. Bewaar ze server-side, bijvoorbeeld in Secret Manager of in Firestore met strikte security rules. Wat de client niet kan zien, kan een aanvaller ook niet stelen.
:::

## Veelgestelde vragen

:::faq
### Kan ik Firebase gebruiken met een gratis Google-account?
Firebase Authentication werkt met elk Google-account. Voor organisatiebrede Workspace-API-toegang via domain-wide delegation heb je wel een Workspace-domein en admin-rechten nodig.

### Is de hd-parameter genoeg om mijn app te beperken tot mijn domein?
Nee. De `hd`-parameter is alleen een hint voor de inlogervaring en kan aan de clientkant worden omzeild. Verifieer het domein altijd server-side door de `hd`-claim in het ID-token te controleren met de Admin SDK.

### Wat is het verschil tussen het e-mailadres en de hd-claim controleren?
De `hd`-claim geeft aan dat het account door jouw Workspace-domein wordt beheerd, terwijl een e-mailadres in theorie afwijkend kan zijn. Controleer daarom bij voorkeur de `hd`-claim als bewijs van organisatie-lidmaatschap.

### Hoe bewaar ik Workspace-tokens veilig?
Versleuteld en server-side, bijvoorbeeld in Secret Manager of in Firestore met strikte security rules. Sla ze nooit op in de client en log ze nooit in platte tekst.

### Werkt dit ook voor mobiele apps?
Ja. De Firebase Auth SDK's voor iOS en Android ondersteunen dezelfde Google-provider, en de server-side verificatie in je Cloud Functions blijft identiek.

### Heb ik een sleutelbestand nodig voor het service account?
Op Google Cloud meestal niet. Een Cloud Function draait al onder een service account, dus je gebruikt die identiteit rechtstreeks. Vermijd gedownloade sleutelbestanden waar het kan, want die zijn een risico als ze uitlekken.
:::

Met Firebase als fundament bouw je snel veilige apps die op Workspace-identiteit leunen, met een soepele inlogervaring en stevige server-side controles.