Skip to main content

Sandbox to Live

The sandbox environment

The clickid-sandbox realm is a test environment that mirrors the live IdP but with relaxed authentication requirements:

PolicySandboxLive
Password minimum length8 characters12 characters
TOTP / MFANot requiredRequired after registration
Email verificationSkippedRequired
User registrationOpenOpen
Sector-ID derivationSame algorithm, different pepperFull production pepper
SP metadataSelf-registered via portalSelf-registered via portal
Signing keysSandbox-specific RSA keypairProduction RSA keypair

The sandbox is designed for rapid iteration. You can register test accounts without going through email verification or MFA setup, and the demo user (resident@example.nl) has no TOTP configured.

Sandbox is not for real users

Never put real user data or real credentials into the sandbox environment. The sandbox uses a shared demo user and relaxed security policies.


Testing checklist

Before promoting to live, verify each item in this checklist:

SSO initiation

  • Your SP correctly generates a SAML AuthnRequest with your entity ID
  • The user's browser is redirected to the sandbox IdP via HTTP-Redirect
  • The IdP login page loads correctly (EU Theme visible)

Authentication

  • The demo user (resident@example.nl / Welkom12345!) can log in successfully
  • The browser is POSTed back to your ACS URL after login
  • Your SP validates the SAML Response signature without errors

Assertion contents

  • The NameID element is present in the response
  • The NameID format is urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
  • The NameID value is exactly 24 characters, URL-safe base64 characters (A-Z, a-z, 0-9, -, _)
  • The Issuer in the response matches https://auth.clickid.eu/realms/clickid-sandbox

Stability

  • Log in twice with the same demo user — the sector-ID (NameID) is identical across both sessions
  • (Optional) Register a second SP in the sandbox — the same demo user gets a different sector-ID for the second SP

Error handling

  • Your SP handles a cancelled login gracefully (user clicks "Cancel" on the login page)
  • Your SP handles an expired SAML Response correctly (assertions are valid for 5 minutes)

Going live

Once you have ticked all items in the checklist:

  1. Log into the SP Portal.
  2. Find your SP under Sandbox SPs.
  3. Click Go live.
  4. Read the confirmation dialog carefully — it outlines what changes.
  5. Click Confirm.

The portal creates the SP client in the clickid live realm and sets it to Active. Your sandbox registration remains intact.


Updating your SP configuration

After promotion, update your SP's IdP metadata URL from sandbox to live:

EnvironmentIdP metadata URL
Sandboxhttps://auth.clickid.eu/realms/clickid-sandbox/protocol/saml/descriptor
Livehttps://auth.clickid.eu/realms/clickid/protocol/saml/descriptor

Re-import the IdP metadata in your SAML library. The live realm has different signing keys — you must update your SP's certificate trust configuration.


What changes between sandbox and live

This is the most important section to understand before going live.

Signing keys are different

The sandbox and live realms each have their own RSA keypair for signing SAML Responses. After updating your SP config, verify that your SP is using the live realm's signing certificate.

Sector-IDs are different

The sector-ID formula includes a server-side pepper:

sectorId = BASE64URL(HMAC-SHA256(userId + "|" + spEntityId, pepper))[:24]

The pepper is different for each realm. This means a user who has a sector-ID of aB3kXmQ9nL7rPwT2vYcZ0s in the sandbox will have a completely different sector-ID (e.g. kQ9sPwT3vYaB0c2nL7rXmZ) in the live realm.

Practical implication: if your application stored a user's sandbox sector-ID in a database (e.g. to link it to a user record), you cannot use that stored value to find the same user after switching to live. The first time a user logs in via the live realm, they will appear as a new user to your application.

Planning a migration

If you are migrating existing users from DigiD or another IdP, consider implementing a "first login" linking flow: after the first ClickID live login, prompt the user to confirm their identity (e.g. enter their old username or confirm via email), then associate their new sector-ID with their existing account.

TOTP is required for real users in live

In the sandbox, users can log in with just a password. In the live realm, users must set up TOTP or a passkey during registration. Build your UX to account for this — the first login for a new user will include an MFA setup step.

Test once more after going live

After pointing your SP at the live IdP metadata, do one full login test:

  1. Create a test account in the live realm (or use the seeded demo user if available in your environment)
  2. Complete the full login flow including MFA setup
  3. Verify the sector-ID in the assertion
  4. Confirm your application handles the account correctly