Generally speaking zitadel handles domain in two places.
1) On an instance level (through the system api) you can append as many domains to an instance as needed 2) On an organization level you can allow your customers to "claim" their domain to kind of prevent that any other organization can create usernames with their domain name
Hi there, this answer confuses me: if that's so, how does Zitadel know for which org a user tries to – at least – register to, or wants to login to edit their account? I couldn't find anything on the topic and also ran into the "missing instance" error, when i've tried to do the definition using a custom domain set as primary (org2.my.domainorg2.my.domain vs auth.my.domainauth.my.domain– same issues with a more default users.auth.my.domainusers.auth.my.domain)
Edit: do i understand right that default org and available domains must be added by calling the api directly?
The domains on which you can serve auth requests are configured at instance level and only accessible via System API (which is not directly available on the SaaS service zitadel.cloud. You have to use the ZITADEL Customer Portal application for this instead, where you can purchase a custom domain with a TLS cert).
Just enter the required parameters, enter the organization ID and select the last scope in the list. Click on "Try it out" to test it out on your instance.
The OIDC Playground is for testing OpenID Authentication Requests, giving you more insight how OpenID Connect works and how you can customize ZITADEL behavior with different parameters.