> ## Documentation Index > Fetch the complete documentation index at: https://docs.cosmon.com/llms.txt > Use this file to discover all available pages before exploring further. # Single sign-on (SSO) > Let your team sign in to Argus with your company identity provider over OpenID Connect: what your users see, what your IdP admin configures, and how accounts behave. 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](/getting-started/plans-and-credits). It is configured once per organization, not per workstation. > [!NOTE] > > SSO governs **how people sign in**. Licences are still assigned in the team console — see [Teams](/getting-started/plans-and-credits#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 \** 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 | Requirement | Detail | | - | - | | Plan | Enterprise | | Protocol | OpenID Connect (authorization code flow). SAML 2.0 is available on request — contact [sales@cosmon.com](mailto:sales@cosmon.com). | | Email domain | One or more domains you own, such as `acme.com`. Public mailbox providers (Gmail, Outlook.com, and similar) cannot be enrolled. | | Claims | `sub`, `email`, and optionally `name`. See [Claims](#claims). | | Browser access | Users must be able to reach both the Cosmon sign-in page and your IdP from their default browser. See [IT prerequisites](/architecture/it-prerequisites#identity). | 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](mailto: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: ``` https://desktop-app.cosmon.com/__/auth/handler ``` 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: | Setting | Value | | - | - | | Grant type | Authorization code | | Sign-in redirect URI | The redirect URI from step 1 | | Scopes | `openid`, `email`, `profile` | | Assignment | The users or groups who should be able to use Argus | 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. | Item | Where to find it | | - | - | | Issuer URL | Your IdP's OIDC discovery document (`/.well-known/openid-configuration`) publishes it. For Okta it looks like `https://acme.okta.com`; for Entra ID, `https://login.microsoftonline.com//v2.0`. | | Client ID | The application you created in step 2 | | Client secret | The application you created in step 2 | **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. | Claim | Required | Used for | | - | - | - | | `sub` | Yes | Stable identifier for the user within your IdP | | `email` | Yes | The user's Argus account. Sign-in fails if it is absent. | | `name` | No | Display name shown in Argus | No group or role claims are consumed. Team roles (owner, admin, member) and licences are managed in the Cosmon team console. > [!WARNING] > > 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 login page shows a password field instead of the SSO button** > > 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. > **“Too many sign-in attempts. Please try again in 60 seconds.”** > > 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. > **Your IdP shows a redirect URI mismatch** > > 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. > **Your IdP signs the user in, but Argus reports the sign-in failed** > > The ID token is missing an `email` claim. Confirm the application in your IdP releases the `email` scope for the assigned users. > **The user is signed in, but not on the team that invited them** > > 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. > **“Could not verify your browser”** > > 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](/architecture/it-prerequisites#identity). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.