Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Third-Party Apps Account Block for React

OAuth grants as a table: each app with its access level, grant date and last use, unused apps pinned to the top, scopes in plain words, a Revoke that can be undone and a bulk revoke that asks first.

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 people audit the apps they have authorised, with this OAuth grants table for React with Base UI. A compact header holds the title, one sentence and the one Shine Button, "Revoke 2 unused apps", which opens an Alert Dialog naming them before it revokes them together. Inside a hairline frame with a plus mark on each corner, a native table lists each app with a neutral lettermark tile, its access as an icon and words (Can read, Can read and write, Full access), the day it was granted and when it was last used. An app not used for 90 days before the as-of date reads "Unused 94 days" in an outline Badge and is pinned to the top; "7 apps, 2 unused" is worked out from the data. The app's name opens its row in place to list what it can do in plain words. Revoke takes one app at once, says so in a polite status line and can be undone, and when the last app goes an Empty state offers the same Undo. Below the medium breakpoint each app is a card. It's built from Alert Dialog, Badge, Button, Empty, Shine Button and Guides, with a CSS entrance only. For an account page, an OAuth settings screen or any product with an app marketplace.

FAQ

How do I fill it with my own apps?

Edit APPS. Each app has an id, a two-letter mark for its neutral tile, a name, a level (read, write or full), the ISO days it was granted and last used, and its scopes as short plain sentences. "Today" is the fixed AS_OF day, so ages are counted from that and never from the clock, and UNUSED_DAYS sets how long counts as unused. The order (unused apps first, the longest unused at the top, then the most recently used), the header count, the pinned badge and the bulk button are all worked out from those fields. The tiles are placeholders: drop in logos you have the rights to use.

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

Revoke, the bulk revoke and Undo only change this page's state, and the status line says "in this demo": no token is revoked and no app is told. To wire it, call your server in revoke and revokeUnused to delete the grants (revoking the refresh token at your authorisation server), and load the real grants into APPS. Undo is a courtesy here; with a real revocation the app has to ask for access again, so most products replace it with a Reconnect link.

Why does the bulk revoke ask and a single Revoke doesn't?

One app is a small, visible step with an Undo line directly under it. Revoking several at once is bigger and easy to trigger by accident, so it opens an alert dialog that names the apps, has no outside-click close and starts on Keep them. With no unused app remains the button stays in its place, quiet, and answers "No app is unused" instead of vanishing. The trigger is passed to AlertDialogTrigger through render.

Is the table accessible?

It is a real table with a caption that says how it is ordered, column headers with scope, and a row header for each app whose button names it ("What Zapier can do") and carries aria-expanded and aria-controls; the closed content is inert. Access and last use are said in words as well as icons, and the unused badge is words. Every Revoke names its app. One polite status line reports each revoke, undo and empty press, and focus moves to the next row after a revoke.

How does it look on a phone?

Each app is a card: the tile and name at the start with Revoke at the end, then its access, granted day and last use as labelled lines. The scopes open under the card at full width. The header button drops under the sentence.

  • Pro

    Integrations Account

    Connected apps

    Who can reach which of your data: one set of grants shown by data or by app, each as a removable chip with the access in words, a revoke that can be undone, and counts worked out from the grants.

  • 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

    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

    OAuth Consent Login

    Sign-up and consent

    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.

  • Pro

    A connected apps settings panel with a permission review sheet: each app asks for permissions shown as switches with what they allow, a pause, and a disconnect that confirms first.