Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

SSO Config Account Block for React

Move your account to company sign-in: what changes as a list of terms, three things to tick, a Shine Button that wakes when all hold and a dialog that asks for the company domain, then a Switch back until the password stops.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Let a person move their own account to their company's single sign-on, with this switching panel for React with Base UI. A compact header holds the title and one sentence. Inside a hairline frame with a plus mark on each corner, a vertical divider splits two cells. At the start, "What changes" is a description list of five terms: the password stops after 14 days, passkeys stay, two sessions end, history is kept and the company's admin sets the rules. At the end, "Before you switch" has three Checkboxes to tick, each with a line on why, and the one Shine Button, Switch to single sign-on, stays quiet until all three are ticked. Then it opens an Alert Dialog that says what happens and asks for the company's domain typed, refusing a typo in words under the field. After the switch the panel reads "Using single sign-on" with the day the password stops, the terms change to the past tense and Switch back stays until then. It's built from Alert Dialog, Button, Checkbox, Field, Input, Shine Button and Guides, with a CSS entrance only. For a personal settings page in a product sold to companies.

FAQ

How do I fill it with my own company and terms?

Edit the constants at the top: COMPANY and DOMAIN (the domain the person types, as the admin gave it), GRACE_DAYS (how long the password keeps working and Switch back stays open), SESSIONS, and LINES, the terms, each with a term, what it says before and what it says after. The day the password stops is worked out from a fixed AS_OF day and GRACE_DAYS, never the clock. CHECKS holds the things to tick. The counts, the status line and both tenses are worked out from these.

What stays local, and how do I make it real?

Confirming only flips this page's state: no identity provider is contacted, no session is ended and nothing is stored, and the status line says "in this demo". To wire it, check in confirm that your server accepts the typed domain for this person's organisation, start the redirect to the company's identity provider, end the other sessions there and schedule the password to stop on the cut-off day; Switch back calls the endpoint that cancels the schedule.

Why is the button quiet instead of missing, and why type the domain?

Hiding the main action until it is allowed would make the page jump and leave people wondering where it went. It stays in place with aria-disabled; pressing it says what is missing and focuses the first unticked box. Moving to company sign-in can lock someone out, so the dialog also asks for the domain typed. That slows a careless press without making the careful one hard, and a wrong domain says so in words and keeps the action off. The trigger is passed to AlertDialogTrigger through render, and first focus lands in the domain field.

What does the panel show after the switch?

The boxes give way, in the same place and at the same height, to a confirmation and the day the password stops; the terms at the start switch to the past tense; and the main button becomes an outline Switch back. Pressing it puts the boxes back, unticked, and says so. The two states of each part share one grid cell, so nothing moves when you switch.

Is it accessible?

The terms are a real description list, the boxes are a group with a legend, and each box is named by its title and described by its line. The unseen state of each part is inert and hidden from assistive technology. The dialog traps focus, closes with Escape and has no outside-click close. The domain field names its problem in words with an icon, and one polite status line reports each result. Dates and the domain keep their direction in an RTL layout.

How does it look on a phone?

The two cells stack, terms first. The status line and the main button pin to the bottom of the screen while the boxes scroll under them, so the action is always in reach.

  • Pro

    Go passwordless safely: the sign-in methods ranked by strength as a ladder, the four things that must hold first, and one button that turns the password off only when they all do.

  • Pro

    The sign-in providers linked to an account: each with its address, link date and use history, an Unlink that asks first and refuses on the only way in, an Undo line and quiet buttons to link more.

  • Pro

    When a provider's email is not yours: a table of what each provider returned, a choice under each mismatch to add it as a second email or keep it separate, and a count of sign-ins that would make a new account.

  • Pro

    SAML Setup Settings

    Sign-in and security

    A SAML single sign-on setup sheet shown open over a drawn security page: copy two values, paste the provider's metadata and see what is found (including the certificate's end day read from the certificate), run a local test, then enforce.

  • Pro

    Enterprise SSO Login

    SSO and providers

    A sign-in page for a construction project manager that asks for the workspace address first: it looks the workspace up as you type, offers the right spelling for a typo and turns the button into Continue with SSO.

  • Pro

    An account's two-factor methods as rows with their role, history and a Test that opens a code field in place, Make primary, a guarded Remove, and a Set up that opens a QR code, a key name or a number.