Skip to main content

SP Integration Overview

This section is for service provider (SP) developers who want to authenticate users via ClickID. If you are looking to self-host ClickID rather than integrate as an SP, see Self-Hosting.

What you need​

To integrate with ClickID, you need:

  1. A SAML 2.0 SP implementation in your application. Most frameworks have a SAML library:

    • PHP: onelogin/php-saml
    • Python: python3-saml, pysaml2
    • Java / Spring: spring-security-saml2
    • Node.js: passport-saml, samlify
    • Ruby: ruby-saml
    • .NET: Sustainsys.Saml2

  2. Your SP's SAML metadata XML. This is generated by your SAML library and contains your entity ID, ACS URL, and (optionally) your SP signing certificate.

  3. An account on the SP Portal at portal.clickid.eu.

The two-step process​

ClickID uses a sandbox-first onboarding model. Every SP must pass through the sandbox before going live.

┌─────────────────────────────────────────────────────────────┐
│                    Step 1: Sandbox                          │
│                                                             │
│  Register SP → get sandbox endpoint → test with demo user   │
│  No MFA required, short passwords OK, no email verify       │
└──────────────────────────────┬──────────────────────────────┘
                               │  "Go live" in SP Portal
┌──────────────────────────────▼──────────────────────────────┐
│                    Step 2: Live                             │
│                                                             │
│  SP promoted to live realm → update SP config → re-test     │
│  Full MFA required, real user accounts                      │
└─────────────────────────────────────────────────────────────┘

Why sandbox first?​

  • You can test your integration without creating real user accounts
  • The demo user (resident@example.nl) has no TOTP, so you can iterate quickly
  • You can break things in sandbox without affecting any live users
  • Sector-IDs in sandbox are intentionally different from live — no risk of data mixing

Key integration facts​

Before you start, note these important properties of the ClickID SAML integration:

PropertyValue
NameID formaturn:oasis:names:tc:SAML:2.0:nameid-format:persistent
NameID value24-character URL-safe base64 sector-ID (unique per user+SP pair)
SP binding (AuthnRequest)HTTP-Redirect
IdP binding (Response)HTTP-POST
Response signingRSA-SHA256, signed at Response level
SP signing (AuthnRequest)Optional but recommended

Important: NameID is not a BSN​

ClickID does not issue BSN (Burger Service Nummer) values. The NameID is a pseudonymous identifier specific to your SP. If you are migrating from DigiD and your application stores BSNs, you will need to re-link user accounts on first login after migration (prompt users to confirm their identity via an alternative channel).

Important: sector-IDs are SP-specific​

The same ClickID user logging into two different SPs will have different sector-IDs at each SP. You cannot use sector-IDs to correlate users across services — this is a deliberate privacy protection, not a limitation.

Next steps​

  1. Register your SP — create an account, submit your metadata, get sandbox endpoint
  2. Sandbox to live — test checklist and promotion steps
  3. SAML Reference — endpoints, sample XML, attribute reference