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.
Follow the setup steps
When you open an identity provider, the top of the window shows the SSO setup steps and how many are done. Each pending step has a button that takes you straight to what solves it, such as downloading the metadata, viewing the domain TXT record or testing the login.
The Coodesh added to the provider step is marked done on its own, on the first SSO login that works. The notices right below the list explain what the current state means for people trying to sign in.
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.
Until the record is found, the domain shows as Pending: TXT record missing, with the record name and value right below so you can copy them. Nobody can sign in with SSO while the domain is pending: until then, the sign-in screen sends people to the password.
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.
Turn off password login (optional)
Once SSO is working, you can require everyone to sign in with it. In Security, turn off Enable email and password login and click Save.
The option can only be turned off once the domain is verified and an SSO login has worked. Until then, it stays locked and the screen explains what is missing.
If password login is off and no identity provider works, the Security screen warns that nobody can sign in to the workspace. Click Turn password back on to restore email and password access while you fix SSO.
