Roadmap to integrate cidaas
Integrating cidaas into your business can be done on your own, supported by us, or together with one of our partners. In addition to supporting the standards OAuth 2.0, OIDC, and SAML, we follow an everything is an API approach.
After the decision to go with cidaas, answer these questions:
- How should go-live look like?
- Which system(s) do you want to connect to cidaas from the start, and which after go-live?
- Do you have to migrate any data?
- How should authentication be displayed to the customer?
- Which data needs to be shared with other systems?
The all-time fastest cidaas integration was in less than one day — including sales contact, instance setup, adding cidaas as login provider to customer portals, and go-live.
During the conception phase you should be able to answer all of these questions. Together they influence four categories: Go-live, Data migration, Integration of applications, and Integration of backend systems.
Use the high-level Integration Checklist in kickoffs to capture decisions. For a short overview of typical connection scenarios, see Integrate cidaas into your business.
Go-live
Go-live planning has a big impact on further decisions. Questions 1 and 2 include whether you want to go live with all applications at the same time (all-in-one) or migrate app by app (step-by-step).
Step-by-step
App-by-app means two systems may run in parallel and need permanent synchronization (for example: a user changes their password in system A linked to app A, then logs in to app B connected to system B — they should be able to use the new password).
Benefits
- Smaller work package per go-live
- More time to adapt individual systems
- Lower risk while focusing on one app
All-in-one
With all-in-one you avoid long-running sync complexity. After go-live the old system can be dismantled and the whole landscape benefits from cidaas immediately.
Benefits
- No dependency on the legacy system
- Less maintenance and operating effort
- No complex sync architecture
Timing
Also decide when the system is used the least, or whether there are phases where it can be unavailable.
The target should always be to lose no data and to keep downtime to a minimum.
Example scenarios
:::tip Guidelines only User counts are approximate. Prefer one-time below ~500k users, and long-term / bidirectional sync above ~500k — unless downtime, change rate, or go-live style push you another way. See Migration Overview. :::
Small
- Users to migrate: ~500 (well below ~500k)
- System usage: 8h / 5d normal business hours
- Go-live style: all-in-one
- Migration approach: One-time migration
Go-live can be planned on a weekend.
To-dos at go-live
- Export all users from the old system
- Import the users to cidaas via script
- Deploy new versions of apps
Medium
- Users to migrate: ~100,000 (still below ~500k guideline)
- System usage: 24/7
- Go-live style: all-in-one (single cutover)
- Migration approach: One-time migration (often with a full load days before go-live and a short delta shortly before cutover)
Exporting and importing a large batch still takes time; changes during that window can be lost. Use create-or-update scripts, shorten the freeze window, or switch to long-term sync if the change rate is high. Before go-live, make cidaas available publicly (for example https://customer-prod.cidaas.eu) and run full integration tests against that URL.
To-dos at go-live
- Add CNAME in cidaas (for example
https://accounts.customer.com) - DNS switch
Big
- Users to migrate: several million (above ~500k guideline)
- System usage: 24/7
- Go-live style: step-by-step (or all-in-one after sync)
- Migration approach: Long-term sync for unidirectional prep, or bidirectional long-term sync when apps move one by one
Both systems stay in sync while apps move (bidirectional) or until a single cutover (unidirectional). Before the first go-live, make cidaas available on a defined URL (for example https://accounts.customer.com) and run full integration tests in advance.
To-dos at go-live
- Release specific apps (per wave) or DNS / CNAME cutover after sync
Data migration
If you start on a greenfield, you can skip this section.
Data migration mostly means user migration. If you migrate from another OAuth 2.0 / OIDC solution, app settings can also matter. Do you have existing consent management — should consents be migrated as well?
Should users remain logged in after cutover? Refresh tokens can be migrated into cidaas so clients can obtain new access tokens without forcing a re-login — see Refresh token migration. Short-lived access tokens are typically not migrated.
With an answer to question 3, the next question is how to migrate data to cidaas. We suggest three approaches depending on:
- Amount of data (guideline: one-time below ~500k, sync approaches above ~500k)
- Go-live style — all-in-one or step-by-step
- Expected downtime during go-live
These suggestions are guidelines based on past projects. You can follow another approach or define a best match together with us or a partner.
See also Migration Overview and Migration Planning.
Integration of applications
Connecting your applications to cidaas is based on OIDC and OAuth 2.0. We provide SDKs and plugins to simplify integration — see GitHub.
To choose the best flow for your application, use the following overview:
Flows are described in detail in OAuth2 Flows:
- PKCE
- Device Code Flow
- Client Credentials
Other OAuth 2.0 / OIDC flows are possible and may be required for third-party systems. Where possible, we recommend one of the three above.
When you introduce an OAuth 2.0 / OIDC-based CIAM, login and registration usually move out of the business app onto standalone pages. In cidaas these are hosted pages.
This section addresses question 4: How should authentication be displayed to the customer? cidaas provides a default set of hosted pages that can be customized to a certain level (logo, app name, colors, background, and more). Changes beyond that can be implemented and hosted by you — optionally based on our template.
Hosted pages cover around 20 pages for login, registration, password forgotten, progressive registration, MFA, and more. Depending on the flow, cidaas calls the corresponding page. With progressive registration, an app asks for basic information at registration; if another app needs more data, an additional page collects it later.
See Hosted Page Decisions before you implement or configure pages — for example what is your username? and do you want passwordless authentication?.
You can also create multiple hosted page sets for different look and feel per touchpoint.
Separating business applications from login forms increases security and reduces maintenance cost, because the same hosted pages can be reused across touchpoints.
Integration to system landscape
As outlined in Integrate cidaas into your business, multiple systems can connect to cidaas — CRM, marketing tools, reporting tools, or backend APIs. That maps to question 5: Which data needs to be shared with other systems?
With everything is an API, connecting to cidaas stays flexible. In the other direction, cidaas provides around 100 events (for example user invite, or configuration changes such as app modified).
The following patterns show how common system types connect.
Application-specific backends
With OIDC and OAuth 2.0 you should not only secure portal access, but also authorize calls to your backend. Scopes and roles allow fine-grained access to business data.
To validate tokens in your backend, use a cidaas interceptor or built-in support in your stack (for example Spring Security OAuth2).
Customer Relationship Management
The usual way to connect a CRM is webhooks. Often a wrapper maps cidaas data to the CRM model (or to SOAP / other APIs).
Configure multiple webhook endpoints for multiple events and secure them (OAuth preferred, or an API key). On cidaas 4.x, create webhooks in Trustdesk under Integrations → Webhooks. On older instances, use the Admin Dashboard webhook settings. See Introducing Trustdesk.
Marketing tools
Marketing tools such as Salesforce Marketing Cloud or Emarsys manage campaigns and communication templates. Reusing them with cidaas is common — see Communication Providers.
cidaas consent management can also cover newsletter consents, which are transferred to the marketing tool. These consents can appear in the user profile and be updated by the end user.
To change the communication provider, create one first. On cidaas 4.x, configure providers under Communication in Trustdesk; on older instances use Settings → Communication Provider → E-Mail → Add new E-Mail Provider. Then select that provider in your templates. Besides REST you can also configure SMTP or others.
Reporting tools
cidaas provides a wide range of built-in reports, but customer needs often differ slightly. A practical approach is to feed a reporting tool with the relevant webhook events and build your own filters and views.
Next steps
- Walk through the Integration Checklist
- Plan migration with the Migration Overview if you have legacy users
- Configure the instance using Instance Setup
- Deep-dive into patterns via External Systems Integration