Skip to main content
Enterprise customers can federate Argus sign-in to their own identity provider (IdP) — Okta, Microsoft Entra ID, Google Workspace, Auth0, PingFederate, or any other provider that speaks OpenID Connect (OIDC). Once your email domain is enrolled, everyone at your company signs in through your IdP: no Cosmon password, no separate button to find. SSO is available on the Enterprise plan. It is configured once per organization, not per workstation.
SSO governs how people sign in. Licences are still assigned in the team console — see Teams. Signing in through SSO does not by itself grant a licence.

​
What your users see

Argus uses an identifier-first sign-in: the login page asks for an email address before anything else, and the email domain decides what happens next.
1

Enter a work email

The user opens Argus, which sends them to the Cosmon sign-in page in their default browser. They type their work email and click Continue.
2

Argus recognizes the domain

Because the domain is enrolled for SSO, the page shows Your organization uses SSO and a single Sign in with <your IdP> button. No password field appears.
3

Authenticate with your IdP

The browser redirects to your IdP. The user signs in the way they always do — including any MFA or device policy your IdP enforces. If they already have an IdP session, this step is instant.
4

Return to Argus

Your IdP redirects back to Cosmon, which completes the sign-in and hands the browser back to the desktop application. The user is signed in.
Users on a domain that is not enrolled see a password field at step 2 instead, exactly as before. Enrolling a domain therefore changes nothing for anyone outside it.

​
Requirements

Domains are matched exactly. If your people sign in as both @acme.com and @eu.acme.com, enroll both.

​
Setting up SSO

Enrollment is a short exchange between your IdP administrator and Cosmon. Cosmon registers your IdP as a trusted provider and maps your domains to it; you register Cosmon as a client in your IdP.
1

Tell Cosmon you want SSO

Email support@cosmon.com (or your account manager) with the email domains to enroll and which IdP you use. Cosmon confirms the redirect URI for your tenant — for the shared cloud backend it is:
Single-tenant deployments get a redirect URI on their own sign-in domain.
2

Create an OIDC application in your IdP

In your IdP’s admin console, create a new web application using OpenID Connect with these settings:Your IdP issues a client ID and a client secret for the application.
3

Send Cosmon the provider details

Share the following with Cosmon. Send the client secret through a secure channel — never in plain email.
4

Test with one user

Cosmon registers the provider and maps your domains, then asks you to confirm. Have one assigned user sign in from the Argus login page: they should see Your organization uses SSO and land back in the app after authenticating with your IdP.
5

Roll out

Assign the application to the rest of your users in your IdP. Nothing changes on the workstations — the same Argus build discovers SSO from the email domain.

​
Claims

Cosmon reads the following claims from the ID token your IdP issues. No group or role claims are consumed. Team roles (owner, admin, member) and licences are managed in the Cosmon team console.
The Argus account is keyed by the email your IdP returns, and that address is taken as-is once the user is back from your IdP. Make sure the application releases each user’s primary work address: if it returns an alias or a personal address, the user is signed in to an account under that address instead of the one their colleagues invited.

​
How accounts behave

Accounts are created on first sign-in. There is no separate provisioning step: a user who authenticates through your IdP for the first time gets an Argus account for that email. To give them a licence, invite them to your team or assign them a seat in the team console. Existing accounts are kept. If someone already had an Argus account with the same email — for example, they signed up with a password before SSO was enrolled — their first SSO sign-in links to that account. Chat history, team membership, and licence carry over. From then on, the password path is no longer offered for that domain. Sign-in follows your IdP. Disabling or unassigning a user in your IdP stops them from signing in again. A desktop session that is already open stays valid until it expires or the user signs out. To cut off team access immediately, also revoke their licence in the team console — that takes effect at once and drops them to a personal Free account. Automated provisioning (SCIM) is not available. Users are provisioned just-in-time as described above.

​
Troubleshooting

The email domain is not enrolled, so the page falls back to the password path. Check that the user typed their work address (not a personal one) and that the exact domain — including any subdomain — is in the list you gave Cosmon. Contact Cosmon to add a missing domain.
The sign-in page rate-limits domain lookups per network address. On a shared corporate egress this can trip if many people sign in at once. Wait a minute and retry.
The redirect URI registered in your IdP’s application does not exactly match the one Cosmon gave you. Compare scheme, host, and path character by character.
The ID token is missing an email claim. Confirm the application in your IdP releases the email scope for the assigned users.
Your IdP returned a different address than the one the invitation went to — an alias, a secondary domain, or a personal address. Fix the released email in your IdP, or re-invite the address it returns.
The Cosmon sign-in page includes a bot-protection check served from challenges.cloudflare.com. Ad-blockers, privacy extensions, and inspecting proxies that block that host make the check fail. Allow the host in the browser and on the network egress path — see IT prerequisites.