Coodesh supports integration with identity providers through SAML SSO, making user login more secure and centralized. Here is how to set up SSO (Single Sign-On) access in your workspace.
Prerequisites
A corporate plan with SAML SSO support.
Administrator permission in your Coodesh workspace.
Access to your identity provider admin panel (e.g. Microsoft Entra ID, Google Workspace, Okta, Auth0).
Set up your identity provider
To enable SAML SSO, go to Workspace > Security in your workspace panel.
Click Add Identity Provider and fill in your identity provider details:
Name
Set a custom name to identify this provider.
Description
Optional field. Explain what this identity provider is used for.
Identity Provider SSO URL
The authentication consumption URL.
Identity Provider Entity ID
The unique identifier of the application.
Public certificate (X.509)
The certificate required for SAML authentication.
Click Continue to save the settings and move on to the next step.
Add authorized domains
Under Authorized domains, add every email domain that will be allowed to authenticate through SSO.
Click Add domain.
Follow the verification instructions (usually by adding a TXT record to your domain DNS).
Click Verify after updating your DNS provider.
Note: DNS propagation can take a few minutes.
Why do we ask for a TXT record in DNS?
The TXT record plays an essential role in the SSO flow: proving that your organization actually owns the domain before Federated Authentication is enabled for the users of that domain.
When SSO is enabled for a domain (for example, company.com), every Coodesh user with an email under that suffix starts being redirected to the configured identity provider. Without proof of ownership, any customer could in theory claim a domain they do not own and intercept legitimate logins. The TXT record is the barrier that prevents this scenario, because only whoever controls the authoritative DNS of the domain is able to publish it.
Why TXT and not another record type
TXT is the standard mechanism (RFC 1464) for publishing arbitrary metadata in DNS without affecting name resolution for the domain:
It does not impact email routing, web traffic, or any service already in production.
It is the same model already used by SPF, DKIM, and DMARC, so your DNS team already knows the procedure.
It allows a unique token generated by Coodesh to be included, unequivocally proving control over the domain.
Industry standard
This procedure is adopted by virtually every SSO and federation provider, including Microsoft Entra ID (Azure AD), Google Workspace, Okta, Auth0, and AWS IAM Identity Center. The requirement follows from the principle that whoever controls DNS controls the domain.
Keeping the record: we recommend keeping the TXT record published for as long as SSO is active. Coodesh may run periodic revalidations to make sure domain ownership has not been transferred to a third party.
Configure the identity provider
In your identity provider panel:
Create a new custom SAML application.
Fill in the Coodesh details that become available once your identity provider has been created:
Assertion Consumer Service URL
Copy the link from the “Assertion Consumer Service URL” field.
Entity ID
Copy it exactly as shown in “Entity ID”.
Start URL
Copy it exactly as shown in “Start URL”.
NameID
Select the user email option in the settings of your custom SAML application.
Map the required attributes:
email: user email
firstName: first name
lastName: last name
Finish and test authentication
Once the domain has been validated, test the login by clicking the Test SAML button.
We recommend keeping email login active until SSO validation is complete.