Fix sso-sql.md: Clarify JWT auth independence and add v25.4 features

This commit addresses critical documentation issues in sso-sql.md where JWT
authentication was incorrectly presented as requiring OIDC/DB Console
configuration. JWT authentication works independently with external IdPs.

Changes to sso-sql.md:
- Rewrite intro to clarify JWT tokens come from external IdPs (primary method)
- Position DB Console JWT generation as optional convenience feature
- Add v25.4 features introduction (JWT authorization, user provisioning)
- Fix prerequisites: remove incorrect OIDC requirement, clarify user provisioning
- Update "Authenticate to your cluster" section to distinguish two JWT methods
- Remove product scope restrictions (Enterprise license no longer required)
- Remove misplaced callout about DB Console availability

Changes to sso-db-console.md:
- Add callout clarifying Basic/Standard clusters lack DB Console access
- Link to cloud-sso-sql.md for alternative authentication on those tiers

Based on evidence from:
- Engineering docs (jwtauthccl package architectural independence)
- Release history (JWT auth v22.2, DB Console generation v23.1)
- Cloud docs (cloud-sso-sql.md explicitly mentions "external IdP")
- Code analysis (no OIDC dependencies in JWT authentication)

Fixes confusion where users believed JWT authentication required DB Console
or OIDC configuration, when it actually works with any external IdP.

Author: mikeCRL

src/current/v25.4/sso-db-console.md

@@ -30,6 +30,9 @@ This SSO implementation uses the [authorization code grant type](https://tools.i
 	- A {{ site.data.products.core }} cluster enabled with a valid [CockroachDB Enterprise license]({% link {{ page.version.version }}/licensing-faqs.md %}#types-of-licenses).
 	- A [CockroachDB {{ site.data.products.advanced }} cluster]({% link cockroachcloud/create-your-cluster.md %}).
 
+{{site.data.alerts.callout_info}}
+CockroachDB {{ site.data.products.cloud }} {{ site.data.products.standard }} and {{ site.data.products.basic }} clusters do not have access to the DB Console. For SQL client authentication on these tiers, refer to [Cluster Single Sign-on (SSO) using the Cloud Console]({% link cockroachcloud/cloud-sso-sql.md %}).
+{{site.data.alerts.end}}
 
 ## Log in to a cluster's DB Console with SSO
 

src/current/v25.4/sso-sql.md

@@ -7,28 +7,30 @@ docs_area: manage
 
 CockroachDB clusters allow users to authenticate with Single Sign-on (SSO), both to the [DB Console]({% link {{ page.version.version }}/ui-overview.md %}), and for SQL client access.
 
-Cluster single sign-on (SSO) enables users to access the SQL interface of a CockroachDB cluster (whether provisioned on CockroachDB {{ site.data.products.cloud }} or {{ site.data.products.core }}) with the full security of single sign-on (SSO), and the choice of a variety of cloud-based or customer-managed identity providers (IdPs).
+Cluster single sign-on (SSO) enables users to access the SQL interface of a CockroachDB cluster (whether provisioned on CockroachDB {{ site.data.products.cloud }} or {{ site.data.products.core }}) with the full security of single sign-on (SSO), using JSON Web Tokens (JWTs) from external identity providers (IdPs) such as Okta, Google, Azure AD, or Keycloak.
 
-{{ site.data.products.advanced }} clusters can provision their users with Java Web Tokens (JWTs) via the DB Console. This allows users to authenticate to a cluster by signing in to their IdP (for example, Okta or Google) with a link embedded in the DB Console. This flow provisions a JWT that a user can copy out of the DB Console UI and use in a SQL connection string to authenticate to the cluster.
+Users can obtain JWTs directly from their IdP and use them to authenticate to SQL clients. Optionally, CockroachDB {{ site.data.products.cloud }} {{ site.data.products.advanced }} clusters and {{ site.data.products.core }} clusters can also generate JWTs via the DB Console as a convenience feature. When DB Console JWT generation is enabled, users can sign in to their IdP through a link embedded in the DB Console, then copy the generated JWT and use it in a SQL connection string to authenticate to the cluster.
 
-{{site.data.alerts.callout_info}}
-Cluster single sign-on for the DB Console is supported on CockroachDB [{{ site.data.products.enterprise }}]({% link {{ page.version.version }}/licensing-faqs.md %}#types-of-licenses) and {{ site.data.products.advanced }} clusters. CockroachDB {{ site.data.products.standard }} and {{ site.data.products.basic }} clusters do not support cluster single sign-on and do not have access to the DB Console. However, both CockroachDB {{ site.data.products.standard }} and CockroachDB {{ site.data.products.basic }} clusters can use [Cluster Single Sign-on (SSO) to authenticate to the `ccloud` command-line interface and to the CockroachDB {{ site.data.products.cloud }} Console]({% link cockroachcloud/cloud-sso-sql.md %}).
-{{site.data.alerts.end}}
+<span class="version-tag">New in v25.4:</span> JWT authentication supports automatic role synchronization and user provisioning. When [JWT authorization]({% link {{ page.version.version }}/jwt-authorization.md %}) is enabled, users' role memberships are automatically synchronized based on group claims from the IdP on each login. Additionally, [automatic user provisioning]({% link {{ page.version.version }}/jwt-authorization.md %}#user-provisioning) can automatically create SQL users on first authentication, eliminating the need to pre-create users.
 
-The page describes how to configure a cluster for cluster single sign-on using JWTs and then how users can authenticate using the JWTs. If you're a user ready to sign in to the DB Console with JWTs, you can skip the configuration section:
+This page describes how to configure a cluster for cluster single sign-on using JWTs and then how users can authenticate using the JWTs. If you're a user ready to sign in to the DB Console with JWTs, you can skip the configuration section:
 
 - [Configure a cluster for cluster single sign-on using JWTs](#configure-your-cluster-for-sso)
 - [Authenticate to your cluster](#authenticate-to-your-cluster)
 
 **Prerequisites**
 
-- You must have your cluster pre-configured for OIDC/SSO authentication for DB Console. Use the [Single Sign-on (SSO) for DB Console]({% link {{ page.version.version }}/sso-db-console.md %}) guide to set this up.
+- **Identity Provider (IdP)**: You must have access to an identity provider that supports JWT tokens, such as Okta, Google, Azure AD, or Keycloak.
+
+- **Cluster Settings Access**: You must have the ability to update your cluster settings. Refer to [`SET CLUSTER SETTING`: Required permissions]({% link {{ page.version.version }}/set-cluster-setting.md %}#required-privileges).
 
-- SQL users/credentials:
+- **SQL User Provisioning**:
+    - If you are using [automatic user provisioning]({% link {{ page.version.version }}/jwt-authorization.md %}#user-provisioning), SQL users will be created automatically on first authentication.
+    - If automatic user provisioning is disabled, a SQL user that corresponds with your external identity must be pre-created on the cluster. To create users, you must have access to the [`admin` role]({% link {{ page.version.version }}/security-reference/authorization.md %}#admin-role).
 
-    - You must have the ability to update your cluster settings, which can be achieved in several ways. Refer to [`SET CLUSTER SETTING`: Required permissions]({% link {{ page.version.version }}/set-cluster-setting.md %}#required-privileges)
-.
-    - A SQL user that corresponds with your external identity must be pre-provisioned on the cluster. To provision such users, you must have access to the [`admin` role]({% link {{ page.version.version }}/security-reference/authorization.md %}#admin-role).
+- **(Optional) DB Console JWT Generation**: To use the DB Console to generate JWTs (instead of obtaining them directly from your IdP), you must have your cluster pre-configured for OIDC/SSO authentication for DB Console. Use the [Single Sign-on (SSO) for DB Console]({% link {{ page.version.version }}/sso-db-console.md %}) guide to set this up.
+
+- **(Optional) JWT Authorization**: To enable automatic role synchronization based on IdP group claims, see [JWT Authorization]({% link {{ page.version.version }}/jwt-authorization.md %}).
 
 ## Configure your cluster for SSO
 
@@ -269,7 +271,17 @@ If you are going to use JWT user provisioning in conjunction with [JWT authoriza
 
 ## Authenticate to your cluster
 
-Once ConsoleDB SSO and Cluster SSO with JWTs are enabled and your cluster is [properly configured](#) (including mapping authorized external users to SQL roles), users can self-provision auth tokens through a sign-in flow embedded in the DB Console. These tokens (JWTs) are intended as short-lived credentials, and although their expiry depends on the IdP configuration, it is usually 1 hour.
+JWT authentication supports two methods for obtaining tokens:
+
+1. **Obtain JWTs directly from your IdP**: Use your identity provider's API or SDK to generate JWT tokens (e.g., via Okta APIs, Google OAuth, Azure AD). This is the primary method and requires only the JWT authentication cluster settings configured above.
+
+2. **Generate JWTs via DB Console**: If you have [OIDC authentication for DB Console]({% link {{ page.version.version }}/sso-db-console.md %}) configured, users can obtain JWT tokens through the DB Console UI.
+
+This section describes the DB Console method. For obtaining JWTs directly from your IdP, refer to your identity provider's documentation.
+
+### Authenticate using DB Console-generated JWTs
+
+Once DB Console SSO and Cluster SSO with JWTs are enabled and your cluster is [properly configured](#configure-your-cluster-for-sso) (including mapping authorized external users to SQL roles), users can self-provision auth tokens through a sign-in flow embedded in the DB Console. These tokens (JWTs) are intended as short-lived credentials, and although their expiry depends on the IdP configuration, it is usually 1 hour.
 
 {{site.data.alerts.callout_success}}
 This example uses [`cockroach sql`]({% link {{ page.version.version }}/cockroach-sql.md %}), but you can use any SQL client that supports sufficiently long passwords.