## Problem
Our `<Button>` component breaks the default `button` contract by
redefining the `type` prop to set its variant (`primary`, `default`,
etc) instead of the button type (`submit`, `button`, etc).
This is confusing and forces to write more code when using it with
shadcn components that expect/inject the standard button props.
## Solution
- rename the `type` prop to `variant`
- rename the `htmlType` prop to `type`
- propagate the changes where necessary
- format code
## How to test
As this is just prop renaming, if it builds it's ok
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
> [!CAUTION]
> This new SSO field is UI-only until `oidc_issuer` is added to the
`config` object.
## What kind of change does this PR introduce?
Feature
## What is the current behavior?
The SAML SSO provider config form has no way to supply an OIDC Issuer
URL, which is required for enterprise-managed MCP authentication.
## What is the new behavior?
- Adds an **OIDC Issuer URL** field to the SAML SSO provider config form
(`/org/_/sso`) inside an "Advanced settings" collapsible.
- Minor UI touch-ups to that SSO form.
| After |
| --- |
| <img width="1434" height="2458" alt="94962"
src="https://github.com/user-attachments/assets/e56f83cd-6e30-4a3f-a78d-330fc053953a"
/> |
The `oidcIssuer` field is UI-only right now; it renders but does not
write. Before merging:
1. Add `oidc_issuer` to the SSO config API type (removes the `as any`
cast in `SSOConfig.tsx:219`)
2. Add `oidc_issuer: values.oidcIssuer || undefined` to the `onSubmit`
payload at `SSOConfig.tsx:183`
3. Wire the backend endpoint to persist and return the field
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* SSO settings now include an "Advanced settings" collapsible with an
OIDC issuer field.
* **UX / Bug Fixes**
* Small UI/description refinements in SSO forms and attribute-mapping
layouts.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46187?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Cemal Kilic <cemalkilic96@gmail.com>
Co-authored-by: Cemal Kılıç <cemalkilic@users.noreply.github.com>
## What kind of change does this PR introduce?
Chore that resolves DEPR-394.
## What is the current behavior?
This stack is consolidating RHF field-array patterns in smaller
reviewable steps.
After the key/value work lands, repeated single-value inputs are still
implemented separately across auth and SSO forms, and the design-system
docs only document the key/value pattern.
## What is the new behavior?
- adds a shared `SingleValueFieldArray` component in `ui-patterns`
- migrates repeated single-value inputs in:
- Redirect URL allow-list modal
- OAuth app redirect URIs
- SSO domains
- SSO attribute mapping
- documents the single-value pattern in the design system with:
- a dedicated fragment page
- updated forms guidance
- updated form pattern demos
- adds focused redirect URL modal coverage
## Additional context
This is PR 3 of a 3-PR stack for DEPR-394.
Base PR: #44058
## What kind of change does this PR introduce?
UI fix.
## What is the current behavior?
Form contents overflow horizontally on `SSOConfig`’s `AttributeMapping`
section.
## What is the new behavior?
These form contents no longer overflow.
| Before | After |
| --- | --- |
| <img width="1096" height="997" alt="SSO Organization Settings Toolshed
Supabase-BB366F67-15C9-40A3-8CB7-C0DA7363A2EC"
src="https://github.com/user-attachments/assets/daabcba2-408a-4d44-8bf6-beb0c21d12ed"
/> | <img width="1096" height="997" alt="SSO Organization Settings
Toolshed Supabase-550B04A9-5B3C-4BCE-9CE3-C4B5F516BE35"
src="https://github.com/user-attachments/assets/741f6178-7633-4c6d-87cd-6fdd5d0e4606"
/> |
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## feat(sso): improve SSO management UX (safe deletion + invitation type
selection)
This PR improves the SSO management experience by introducing a safer
deletion flow for SSO providers and allowing explicit control over
invitation authentication type.
## SSO Provider Deletion Improvements
The SSO provider deletion flow has been redesigned to better communicate
the impact of the action and prevent accidental destructive operations.
### UX Improvements
* Replace `ConfirmationModal` with `TextConfirmModal` in `SSOConfig`
* Require typing the SSO domain to confirm deletion
* Display the number of organization members authenticating via SSO who
will be removed
* Add destructive visual styling and clear warnings about irreversible
consequences
* Update confirmation button label to emphasize impact:
* `I understand, delete SSO provider and members`
### Warning Content
The modal now clearly communicates:
* The domain being deleted
* That SSO authentication will be disabled
* That SSO-authenticated members will be permanently removed
* That those members must be re-invited to regain access
If SSO members exist, a highlighted destructive warning box shows:
```
X organization member(s) who authenticate via SSO will be permanently removed
```
### Implementation Details
* Add `useOrganizationMembersQuery` to fetch organization members
* Calculate SSO members by filtering `is_sso_user === true`
* Only display the member warning when the count > 0
* Modal uses `variant="destructive"` and `size="small"`
This pattern follows the existing **Delete organization** confirmation
flow.
### Initial Delete Support
This PR also introduces the underlying deletion functionality:
* Add `useSSOConfigDeleteMutation`
* Add delete button (trash icon, danger styling) in the SSO config
footer
* Layout mirrors `CustomDomainDelete` pattern:
* delete button on the left
* save/cancel actions on the right
* Success toast shown after deletion
* Form resets to explicit default values after deletion
## Invitation Type Selection
Organizations with SSO configured can now explicitly choose the
authentication method when inviting new members.
Previously, invitations always inherited the inviter's authentication
method. This made it difficult to support mixed authentication
organizations.
### New Invitation Options
When SSO is enabled, the invite dialog now shows an **Invitation type**
dropdown:
* **Automatic (based on your account)**
Default behavior; inherits authentication method from the inviter.
* **Require SSO authentication**
Sends an SSO invitation.
* **Email/password authentication**
Sends a non-SSO invitation.
### Implementation Details
* Add `useOrgSSOConfigQuery` to detect if SSO is configured
* Add `requireSso` field to the form schema with enum:
* `auto`
* `sso`
* `non-sso`
* Only display the dropdown when the organization has an SSO provider
* Transform form values before sending to the backend:
```
sso -> { requireSso: true }
non-sso -> { requireSso: false }
auto -> {} (omit parameter)
```
* Update `OrganizationCreateInvitationVariables` to include optional
`requireSso`
* Preserve backward compatibility by only sending the field when
explicitly set
## Bug Fixes
* Attribute mapping preset buttons (Azure, GSuite, Okta) now properly
mark the form as dirty so the save button becomes enabled
* Form reset after deletion now uses explicit default values instead of
the last saved state
## Problems Solved
This PR addresses several UX issues:
1. Deleting an SSO provider previously used a simple confirmation with
no explanation of impact
2. Users could not see how many members would be affected by deletion
3. The destructive and irreversible nature of the action was not
visually emphasized
4. Invitations always inherited the inviter's auth method
5. Organizations could not intentionally mix SSO and non-SSO users
## Types
TypeScript types in `api-types` were updated to support the new
`require_sso` parameter.
---------
Co-authored-by: Chris Stockton <chris.stockton@supabase.io>
Co-authored-by: Ali Waseem <waseema393@gmail.com>
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
* Start
* Add join org logic
* Regenerate the API types and add RQ hooks.
* Various fixes to the UI for SSO config.
* Refactor the components to use RHF.
* Fix the loading/error states in the main file.
* fix: minor changes to SSO UI
* Expanded default attribute mapping preset for `Okta` to include `user_name`, `first_name`, and `last_name` to match our docs.
* Normalized role casing in the "Join Organization on Signup" dropdown to match the roles expected by the backend (`Owner`, `Administrator`, `Developer`).
* Added the role (`Read-only`) to the selectable roles for auto-join.
* Call update mutation when an `ssoConfig` has been retrieved.
* Treats `404` as a valid "create" flow state rather than an error.
* Conditionally renders the SSO config form when config is successfully loaded *or* when the provider is not found, allowing users to onboard from scratch and disable the provider.
* chore: prettier
* feat: add a button linking to SSO setup docs
* Revert "feat: add a button linking to SSO setup docs"
This will be included in a separate docs pr.
This reverts commit 0b616fdd2e.
* General clean up
* Nit copy
* Add empty state for SSO
* Smol change
* One last tweak
---------
Co-authored-by: Chris Stockton <180184+cstockton@users.noreply.github.com>
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
Co-authored-by: Chris Stockton <chris.stockton@supabase.io>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
