> ## Documentation Index > Fetch the complete documentation index at: https://radarhq.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Sign-in and access: which path applies > Before the SSO, members, domains and IdP-groups pages: which of them applies to your situation, and how the pieces combine. Two separate questions decide how someone gets into your Radar Cloud organization, and the pages in this section answer them one feature at a time. Keep them apart and the rest is simple: 1. **How does a person prove who they are?** The Cloud sign-in page, or your identity provider through SSO. 2. **How does that person become a member of your organization?** An invitation, auto-join on a verified email domain, or signing in through your organization's own link. The two questions are decided separately, and most organizations use more than one answer to each. Start here, then follow the link for the piece you need. ## First: Cloud or self-hosted? Everything below is about **Radar Cloud** (app.radarhq.io). A [self-hosted Hub](/docs/cloud/self-hosted) does not use WorkOS or any of it: people sign in with **your OIDC provider directly**, plus a permanent break-glass admin account. The first person to sign in becomes owner, later people join with the default role you configure, and owners manage roles from there. See [Self-hosted authentication](/docs/cloud/self-hosted/auth) and stop reading this page. ## How people prove who they are * **The Cloud sign-in page** - the methods offered there (an emailed code, and the providers Radar Cloud enables). Nothing to set up on your side. * **Your identity provider through SSO** - SAML or OIDC, connected self-serve from Settings on the Enterprise and Custom plans. See [SSO](/docs/cloud/sso). Connecting SSO adds a door; it does not close the others. A **Require single sign-on** switch is not available yet, so a member who already has an account can still use the Cloud sign-in page. ## How people become members Three paths. They can all be on at once; only the third involves your identity provider. | Path | What has to be true | Role they get | Set up | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ----------------------------------------------- | | **Invitation** | An owner invited their email, and they accepted the invitation with a matching address before it expired | The role on the invitation (an existing membership keeps its role) | [Members](/docs/cloud/members) | | **Domain auto-join** | The organization has verified the email's domain on the Domains page, that domain's auto-join switch and the organization-wide auto-join switch are both on, and the email is verified (see below) | Default invite role | [Members](/docs/cloud/members#domain-auto-join) | | **Signing in through your organization** | They authenticated in your organization's scope - usually by opening `app.radarhq.io/login/` with SSO configured - and WorkOS returned your organization as the one that admitted them | Default invite role on first sign-in; an existing membership keeps its role | [SSO](/docs/cloud/sso#per-organization-sign-in-link) | The third path is worth stating plainly: whoever WorkOS admits *to your organization* becomes a member - through your IdP's connection, or through any other sign-in method routed in your organization's scope. Radar adds no gate of its own there, and the organization-wide auto-join switch does not affect it (it governs domain-based joining only). Your identity provider's admission policy is the gate, which is exactly what makes this the right path for [contractors and guests](/docs/cloud/sso-external-users). ## What a verified domain does A domain you add under **Settings → Organization → Domains** and verify with one DNS-TXT record (at the domain you are verifying, not its parent) does three separate things: * **Routes SSO sign-ins**, once SSO is configured. A person who types an address at a verified domain on the sign-in page is sent to your IdP. Without a verified domain, your organization's sign-in link routes them instead. * **Makes auto-join possible** for addresses at that domain (with the switches above). * **Is where rewritten guest addresses land**, if you onboard external users through the subdomain alternative - a verified subdomain such as `ext.example.com`. A domain that is added but not yet verified is claimed and does nothing until the record is in place. ## Where "verified email" comes from Radar trusts WorkOS's verification status for the address. An address your IdP asserts through SSO at a domain you verified arrives verified, and so do sign-ins WorkOS can verify on its own (an emailed code you entered, or a provider that vouches for the address). When WorkOS decides an address still needs proving - for example an SSO assertion for an address outside your verified domains - it emails a code and Radar collects it. That is the normal experience for a guest who keeps their employer email; the guest flow's subdomain alternative avoids it, because an address at a verified domain, asserted by your connection, is not challenged. ## On top of any of the above * **Cluster access that follows your directory groups.** SSO plus a groups claim from your IdP, passed through to Kubernetes as `radar:idp:` subjects you bind yourself. Bindings only add permissions: the baseline Cloud role still grants what it grants unless you turn that tier's defaults off. See [IdP groups](/docs/cloud/idp-groups) and [RBAC](/docs/cloud/rbac). * **Guests who keep their employer email.** They sign in through your organization's link with their real address, confirm it with an emailed code, and join with the default role; OIDC or SAML, your choice. If you would rather they never see the code, the documented alternative rewrites guests onto a subdomain you verified and carries the real address as a separate claim; that recipe is written for a **SAML** connection. See [SSO for external users](/docs/cloud/sso-external-users). ## SAML or OIDC? Either: your IdP's choice, for employees and guests alike. Only the subdomain-rewrite alternative for guests is documented for SAML. And note that "OIDC" on a self-hosted Hub is a different mechanism entirely - a direct connection with no WorkOS - so the Cloud SSO pages do not apply there.