docs(cloud): social sign-in works on any custom domain (off-eTLD no longer requires BYOC)

content/en/cloud/guides/organizations/configuration-scenarios/index.md

@@ -54,10 +54,11 @@ host with the default identity providers.
 | **Front door** — where your users sign in | **Shared** (the deployment's address, e.g. `cloud.layer5.io`) · **Branded subdomain** (a subdomain of the deployment's base domain, e.g. `acme.layer5.io`) · **Custom domain** (your own domain, e.g. `cloud.acme.com`) |
 | **Identity provider** — who runs sign-in | **Shared/default** (the deployment's Google + GitHub apps) · **Your own (BYOC)** (your own Google, GitHub, and/or OIDC single sign-on) |
 
-The interesting wrinkle is **social sign-in** (the Google / GitHub buttons).
-Email-and-password sign-in works in *every* scenario; whether the social
-buttons appear depends on how your domain and identity provider line up —
-which is exactly what the named scenarios capture. (See
+Both email-and-password and social sign-in (the Google / GitHub buttons)
+work in *every* scenario, including on a fully-custom domain using the
+deployment's default identity providers. What the named scenarios capture is
+*whose* identity provider authenticates your users and *whose* brand appears
+on the consent screen — not whether social sign-in is available. (See
 [White-labeling → Social sign-in on a custom domain](/cloud/guides/self-hosted/white-labeling/#social-sign-in-on-a-custom-domain)
 for details.)
 
@@ -68,8 +69,8 @@ for details.)
 | **Hosted** | Shared (`cloud.layer5.io`) | Shared/default | ✅ Works | You just want an organization — no custom URL, no setup. |
 | **Branded** | Branded subdomain (`acme.layer5.io`) | Shared/default | ✅ Works | You want a branded sign-in URL and pages, but are happy using the platform's Google/GitHub apps. |
 | **Branded + BYOC** | Branded subdomain | Your own (BYOC) | ✅ Works (your consent screen) | You want a branded subdomain **and** your own OAuth apps or single sign-on. |
-| **White-Label (Password-Only)** | Custom domain (`cloud.acme.com`) | Shared/default | ⚠️ Hidden | You want your own domain quickly and email-and-password sign-in is enough for now. |
-| **White-Label** | Custom domain | Your own (BYOC) | ✅ Works (your consent screen) | You want a fully branded deployment on your own domain, end to end. |
+| **White-Label** | Custom domain (`cloud.acme.com`) | Shared/default | ✅ Works | You want your own domain, with social sign-in working out of the box on the platform's Google/GitHub apps. |
+| **White-Label + BYOC** | Custom domain | Your own (BYOC) | ✅ Works (your consent screen) | You want a fully branded deployment on your own domain, end to end. |
 
 Read the table top-to-bottom as a ladder: each rung gives your organization
 more of its own identity. One combination is intentionally **not possible**
@@ -124,25 +125,24 @@ provider for single sign-on.
   **distinct authentication boundary** — see [Identity Services → The
   identity provider is the security boundary](/cloud/guides/self-hosted/planning/identity-services/#the-identity-provider-is-the-security-boundary).
 
-### White-Label (Password-Only)
+### White-Label
 
 Your organization runs on **your own domain** (`cloud.acme.com`, on a
-different base domain from the deployment), but still uses the deployment's
+different base domain from the deployment), using the deployment's
 **default** identity providers.
 
 - **Branding:** fully white-labeled sign-in pages on your own domain.
-- **Sign-in:** email and password work fully — both sign-up and sign-in. The
-  **Google/GitHub buttons are hidden**, because the secure social-sign-in
-  handshake cannot hand off between two unrelated domains using the shared
-  apps. The **Log In / Sign Up** toggle stays visible, so users can still
-  register and sign in with email and password.
-- **Choose it when:** you want your own domain quickly and email-and-password
-  sign-in meets your needs for now. **To turn the social buttons back on,
-  add your own identity provider** and you become a full *White-Label*
-  organization (below). See the
-  [note on hidden social buttons](/cloud/guides/self-hosted/white-labeling/#social-sign-in-on-a-custom-domain).
+- **Sign-in:** email and password, as well as Google and GitHub, all work out
+  of the box — the social buttons use the platform's Google/GitHub apps, so
+  the upstream consent screen shows the platform's name.
+- **Choose it when:** you want your own domain with social sign-in working
+  immediately, and you don't need your own OAuth apps or consent-screen
+  branding. **To bring your own OAuth apps or corporate single sign-on, add
+  your own identity provider** and you become a *White-Label + BYOC*
+  organization (below). Set up the custom domain in
+  [White-labeling → Custom Domain Name and Login Screen](/cloud/guides/self-hosted/white-labeling/#custom-domain-name-and-login-screen).
 
-### White-Label
+### White-Label + BYOC
 
 The top of the ladder: **your own domain** *and* **your own identity
 provider**. Your organization is branded end to end and authenticates
@@ -172,15 +172,17 @@ A quick way to land on the right scenario:
 2. **Do you need your own identity provider** — your own Google/GitHub apps,
    your own consent-screen branding, or your corporate single sign-on?
    - On a **subdomain**: No → **Branded**. Yes → **Branded + BYOC**.
-   - On **your own domain**: No → **White-Label (Password-Only)** (email and
-     password only). Yes → **White-Label** (the full experience).
+   - On **your own domain**: No → **White-Label** (social sign-in works on the
+     platform's apps). Yes → **White-Label + BYOC** (the full experience).
 
 {{< alert type="info" >}}
-**Rule of thumb.** Your own domain on a *different* base domain from the
-deployment? Bringing your own identity provider is **required** for social
-sign-in. A subdomain of the deployment's base domain? It's **optional** —
-only for your own branding, scale, or isolation. The full optional-vs-required
-breakdown is in [Identity Services → When BYOC is optional vs. required](/cloud/guides/self-hosted/planning/identity-services/#when-byoc-is-optional-vs-required).
+**Rule of thumb.** Social sign-in works out of the box in every scenario —
+including on your own domain on a *different* base domain from the deployment —
+using the platform's identity providers. Bringing your own identity provider
+is **always optional**, whatever your domain: choose it only when you want
+your own consent-screen branding, your own OAuth rate limits and audit trail,
+corporate single sign-on, or a distinct authentication boundary. The full
+breakdown is in [Identity Services → BYOC is always optional](/cloud/guides/self-hosted/planning/identity-services/#byoc-is-always-optional).
 {{< /alert >}}
 
 ## These choices are independent of who can join

content/en/cloud/guides/self-hosted/planning/identity-services/index.md

@@ -35,16 +35,16 @@ By default, every organization signs users in through your deployment's **shared
 
 An organization can optionally **bring its own credentials (BYOC)**: its own Google OAuth client and GitHub OAuth App. With BYOC, the upstream consent screen, the registered redirect URL, and the entire OAuth round trip carry the organization's own branding and stay on the organization's own domain. BYOC is enabled per organization by a [Provider Administrator]({{< ref "cloud/concepts/identity-and-security/roles/_index.md#provider-admin-role" >}}); an organization owner then registers the OAuth client ID and secret.
 
-### When BYOC is optional vs. required
+### BYOC is always optional
 
-Whether BYOC is *optional* or *required* depends on your organization's [custom domain]({{< ref "cloud/guides/self-hosted/white-labeling/_index.md#social-sign-in-on-a-custom-domain" >}}) and how it relates to the **base domain** (the registrable domain, or eTLD+1) of your deployment:
+BYOC is **always optional**. Social sign-in (Google and GitHub) works out of the box on every [custom domain]({{< ref "cloud/guides/self-hosted/white-labeling/_index.md#social-sign-in-on-a-custom-domain" >}}) — including a fully-custom domain on a different **base domain** (the registrable domain, or eTLD+1) from your deployment — using the deployment's default identity providers. You bring your own credentials only when you want your own brand, controls, or isolation, never to make social sign-in available:
 
 | Organization's domain | Default identity providers | BYOC |
 | --- | --- | --- |
 | No custom domain, or a subdomain of the deployment's base domain (e.g. `team.example.com` on a `cloud.example.com` deployment) | Social sign-in works out of the box | **Optional** — only for your own branding, scale, or isolation |
-| A fully-custom domain on a different base domain (e.g. `meshery.yourcompany.com` pointed at the hosted `cloud.layer5.io`) | Social sign-in cannot complete | **Required** for Google / GitHub sign-in |
+| A fully-custom domain on a different base domain (e.g. `meshery.yourcompany.com` pointed at the hosted `cloud.layer5.io`) | Social sign-in works out of the box | **Optional** — only for your own branding, scale, or isolation |
 
-On a fully-custom domain **without** BYOC, the Google and GitHub buttons are hidden on the login and sign-up screens. Email-and-password sign-in and sign-up both remain fully available — the **Log In / Sign Up** toggle stays visible, so new users can still register and existing users can still sign in. Only the social buttons are hidden; configuring the organization's own identity providers restores them on that domain.
+On a fully-custom domain, the Google and GitHub buttons are shown alongside email-and-password sign-in and work without any per-organization configuration. Configuring the organization's own identity providers (BYOC) changes *whose* OAuth apps and consent screen are used — it does not gate whether social sign-in is available.
 
 ### The identity provider is the security boundary
 
@@ -58,10 +58,10 @@ Organizations that share an identity provider sit within the same authentication
 | --- | --- | --- | --- |
 | **Canonical host** | `cloud.layer5.io` | The deployment's shared, central provider | The shared boundary |
 | **On-eTLD custom host** (a subdomain under the same base domain as the canonical host) | `partner.layer5.io` on a `cloud.layer5.io` deployment | The same shared, central provider | The **same** shared boundary as the canonical host |
-| **Off-eTLD custom host** (a fully-custom domain on a different base domain) | `meshery.yourcompany.com` pointed at `cloud.layer5.io` | The organization's own (BYOC) provider | A **distinct** boundary |
+| **Off-eTLD custom host** (a fully-custom domain on a different base domain) | `meshery.yourcompany.com` pointed at `cloud.layer5.io` | The same shared, central provider (unless BYOC is configured) | The **same** shared boundary as the canonical host (unless BYOC is configured) |
 | **Any host, with BYOC** | any of the above, after configuring BYOC | The organization's own dedicated provider | A **distinct** boundary |
 
-The canonical host and on-eTLD custom hosts typically draw on the shared, central identity provider, so organizations reached through them are within one shared authentication boundary. An organization with its own (BYOC) identity provider is its own boundary, no matter how its host is named. The DNS shape of the host is not the boundary — the identity provider behind it is.
+By default, every host class — canonical, on-eTLD, and off-eTLD — draws on the shared, central identity provider, so organizations reached through them sit within one shared authentication boundary. An organization with its own (BYOC) identity provider is its own boundary, no matter how its host is named. The DNS shape of the host is not the boundary — the identity provider behind it is.
 
 This is the authentication (host-class) view of the boundary. It composes with the **authorization** view — where each organization context independently scopes what a user is permitted to do via [keys]({{< ref "cloud/concepts/identity-and-security/keys.md" >}}), [keychains]({{< ref "cloud/concepts/identity-and-security/keychains.md" >}}), and [roles]({{< ref "cloud/concepts/identity-and-security/roles/_index.md" >}}) — and with **granular** resource-access sharing that can cross organizations. For the complete picture of how these layers fit together, see [Identity and Security → Security Boundaries]({{< ref "cloud/concepts/identity-and-security/_index.md#security-boundaries" >}}).
 

content/en/cloud/guides/self-hosted/white-labeling/_index.md

@@ -188,17 +188,17 @@ Optionally, to enforce HTTPS encryption for your site, select Enforce HTTPS. It
 
 ### Social sign-in on a custom domain
 
-Whether social sign-in (Google and GitHub) works on a custom domain depends on how that domain relates to the **base domain** of your Layer5 Cloud deployment — its registrable domain, technically the [eTLD+1](https://developer.mozilla.org/en-US/docs/Glossary/eTLD) (for example `layer5.io` or `example.com`).
+**Social sign-in (Google and GitHub) works on any custom domain** — whether it is a subdomain of your deployment's **base domain** (its registrable domain, technically the [eTLD+1](https://developer.mozilla.org/en-US/docs/Glossary/eTLD), for example `layer5.io` or `example.com`) or a fully-custom domain on a different base domain. In every case, the Google and GitHub buttons appear and complete sign-in using the deployment's default identity providers. No per-organization setup is required, and bringing your own identity provider is **not** a prerequisite for social sign-in.
 
-- **Same base domain.** If the custom domain is a subdomain of your deployment's base domain — for example a deployment at `cloud.example.com` with a `meshery.example.com` custom domain (or, on the hosted service, a Layer5-provisioned partner subdomain such as `partner.layer5.io`) — the sign-in session is shared across that base domain, so **Google and GitHub sign-in work out of the box** with the deployment's default identity providers. No per-organization setup is required.
+- **Same base domain.** If the custom domain is a subdomain of your deployment's base domain — for example a deployment at `cloud.example.com` with a `meshery.example.com` custom domain (or, on the hosted service, a Layer5-provisioned partner subdomain such as `partner.layer5.io`) — Google and GitHub sign-in work out of the box with the deployment's default identity providers.
 
-- **Different base domain (fully-custom).** If the custom domain sits on a different base domain — for example you CNAME `meshery.yourcompany.com` to the hosted `cloud.layer5.io`, where `yourcompany.com` and `layer5.io` are different base domains — the secure social sign-in handshake cannot hand off between the two unrelated domains using the shared default identity providers. **Social sign-in on a fully-custom domain therefore requires your organization to bring its own identity provider credentials (BYOC)**: your own Google OAuth client and GitHub OAuth App, registered against your domain.
+- **Different base domain (fully-custom).** If the custom domain sits on a different base domain — for example you CNAME `meshery.yourcompany.com` to the hosted `cloud.layer5.io`, where `yourcompany.com` and `layer5.io` are different base domains — Google and GitHub sign-in still work out of the box, again using the deployment's default identity providers. You only need to bring your own identity provider credentials (BYOC) if you want your own brand on the consent screen, your own OAuth rate limits and audit trail, corporate single sign-on, or a distinct authentication boundary — never merely to enable social sign-in.
 
-{{< alert title="Social buttons are hidden until your own identity providers are configured" color="info" >}}
-On a fully-custom domain **without** its own identity providers, the Google and GitHub buttons are **hidden** on the login and sign-up screens — they would otherwise lead to a sign-in that cannot complete. **Email-and-password sign-in and sign-up both remain fully available** — the **Log In / Sign Up** toggle stays visible, so new users can still register and existing users can still sign in. Only the social buttons are hidden. They reappear automatically once your organization configures its own identity providers. See [Identity Services]({{< ref "cloud/guides/self-hosted/planning/identity-services/index.md" >}}) for what BYOC is and when it is required.
+{{< alert title="Social sign-in works without bringing your own identity providers" color="info" >}}
+On any custom domain, the Google and GitHub buttons are **shown** and fully functional alongside email-and-password sign-in, using the deployment's default identity providers — no per-organization configuration is required. Bringing your own identity providers (BYOC) remains optional and changes *whose* OAuth apps and consent screen are used, not *whether* social sign-in is available. See [Identity Services]({{< ref "cloud/guides/self-hosted/planning/identity-services/index.md" >}}) for what BYOC is and when you might want it.
 {{< /alert >}}
 
-The same base domain / different base domain split above is not only about whether social buttons appear — it also marks an **authentication boundary**. Organizations that share an identity provider (the canonical host and on-eTLD custom subdomains that use the shared, central provider) sit within the same authentication boundary, while an organization that brings its own (BYOC) provider is a distinct authentication boundary: **same identity provider source means the same security boundary**, regardless of how the host is named. See [Identity Services → The identity provider is the security boundary]({{< ref "cloud/guides/self-hosted/planning/identity-services/index.md#the-identity-provider-is-the-security-boundary" >}}) and [Identity and Security → Security Boundaries]({{< ref "cloud/concepts/identity-and-security/_index.md#security-boundaries" >}}).
+The same base domain / different base domain split above still marks an **authentication boundary**. Organizations that share an identity provider (the canonical host and custom domains that use the shared, central provider) sit within the same authentication boundary, while an organization that brings its own (BYOC) provider is a distinct authentication boundary: **same identity provider source means the same security boundary**, regardless of how the host is named. See [Identity Services → The identity provider is the security boundary]({{< ref "cloud/guides/self-hosted/planning/identity-services/index.md#the-identity-provider-is-the-security-boundary" >}}) and [Identity and Security → Security Boundaries]({{< ref "cloud/concepts/identity-and-security/_index.md#security-boundaries" >}}).
 
 ## Frequently asked questions about white labeling