Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

OAuth Consent Login Block for React

A consent screen for a calendar when a scheduling app asks for access: two required permissions shown locked, two optional ones you can untick, a button that counts what it grants and a scope details disclosure.

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

Ask clearly before another app gets in, with this OAuth consent login block for React with Base UI. It's the consent screen of Calendrift, a calendar, when Slotbird, a scheduling app, asks for access: the page's side rails run the full height of the screen and one band crosses it between two rules, holding one start-aligned column. A pair of tiles joined by a hairline and an arrow (ours solid, theirs outlined) sits over the heading, which says what Slotbird wants, and the account it would use is named with a "Not you?" link. Four permissions share a hairline group, each a Checkbox row with what it lets the app do: View your profile and See your calendars are Required, ticked and locked, Create events and Delete events are Optional and can be unticked. The Shine Button, the only colored control, counts what it grants ("Allow 3 of 4"), and Deny is a plain outline button. A Scope details disclosure lists the scope strings and the address Slotbird would be sent back to, which follows the ticks. It's built from Checkbox, Button, Shine Button and Guides, with a CSS entrance only. For any product that lets other apps act on its users' data.

FAQ

What stays in the page, and how do I wire a real authorization?

All of it. The four permissions, the account and the addresses are typed; Allow waits a moment and shows what was granted, Deny shows that nothing was shared, and no request is made. In a product this is the page your authorization endpoint renders for a valid request: show the client's registered name, check its redirect address against the registered one, and on Allow issue a code that carries only the scopes that were ticked, then send the person back to the redirect address with it. On Deny, send them back with error=access_denied.

How do required and optional permissions differ?

Required ones are what the app can't work without, so they are ticked and locked and each row says Required with a lock; asking for them is the whole request. Optional ones are extras the person can decline and the app must still work without. Unticking one changes the count on the button ("Allow 2 of 4"), the scope list and the return address, and a polite message says what changed.

What are the scope strings, and why show them?

They are the names the app would send and your server would store, such as events.create. Most people never open the disclosure, but developers and administrators do, and it lists each scope as Allowed or Not allowed with the return address beside it, so what the button counts and what would be sent can be compared.

What keeps a consent screen from being used to trick people?

Name the app and the account in plain words, never let the app supply its own description unchecked, show the registered redirect address, and keep Deny as easy to reach as Allow. This page puts the account and a "Not you?" link above the permissions, so someone on the wrong account can leave before granting anything. Third-party tiles here are neutral lettermarks; use the app's registered logo only after you have verified it.

Why is nothing disabled?

A disabled control can't explain itself and keyboard users can't reach it. The locked permissions are real checkboxes that are ticked and unavailable, with the reason (Required) in text beside them, and both buttons stay available. Deny never waits behind a form or a delay.

What changes on a phone?

Nothing is hidden: the pair, the heading, the account line, the four rows and both buttons stack in one column, with Allow on the first screen. The page is start-aligned, not centered, so opening Scope details only grows it downward, and in an RTL page the arrow between the tiles mirrors while the scope strings and addresses keep their own direction.

  • Pro

    SAML Redirect Login

    SSO and providers

    A sign-in page for payroll that walks through a SAML hand-off one step at a time: five read-only steps, a Now at address, Start redirect, Step and Cancel, and the facts and typed request the two sides agree on.

  • Pro

    OAuth Apps Settings

    API and webhooks

    An OAuth apps settings window with a list of registered apps beside the chosen app's client ID, a masked secret with a confirmed Roll secret, redirect URIs that are checked when added, and grouped scopes with the consent sentence they produce.

  • Pro

    Social Buttons Login

    SSO and providers

    A full-height provider-first sign-in page for a photo-sharing app: four hairline rows for Google, GitHub, Apple and Microsoft with a Last used badge that moves, and an email form that opens in place.

  • 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

    Session Limit Login

    Sessions and devices

    A sign-in gate for a video streaming service: a meter of screens in use, three sessions as radio rows, and one button that ends the chosen session so this browser can continue.

  • Pro

    Cookie Consent Login

    Sign-up and consent

    A bakery subscription's cookie choices shown open over a drawn sign-in page: Essential locked on, Analytics and Marketing switches that start off, and three equal buttons, Reject all, Accept all and Save choices.