Sandbox to Live
The sandbox environment
The clickid-sandbox realm is a test environment that mirrors the live IdP but with relaxed authentication requirements:
| Policy | Sandbox | Live |
|---|---|---|
| Password minimum length | 8 characters | 12 characters |
| TOTP / MFA | Not required | Required after registration |
| Email verification | Skipped | Required |
| User registration | Open | Open |
| Sector-ID derivation | Same algorithm, different pepper | Full production pepper |
| SP metadata | Self-registered via portal | Self-registered via portal |
| Signing keys | Sandbox-specific RSA keypair | Production 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.
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
AuthnRequestwith 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
NameIDelement 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
Issuerin the response matcheshttps://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:
- Log into the SP Portal.
- Find your SP under Sandbox SPs.
- Click Go live.
- Read the confirmation dialog carefully — it outlines what changes.
- 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:
| Environment | IdP metadata URL |
|---|---|
| Sandbox | https://auth.clickid.eu/realms/clickid-sandbox/protocol/saml/descriptor |
| Live | https://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.
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:
- Create a test account in the live realm (or use the seeded demo user if available in your environment)
- Complete the full login flow including MFA setup
- Verify the sector-ID in the assertion
- Confirm your application handles the account correctly