Oauth Consent Blueprint
OAuth grant screen listing exact permissions granted and a cannot list, connecting as a named account, with Authorize and Cancel actions.
OAuth grant screen listing exact permissions granted and a cannot list, connecting as a named account, with Authorize and Cancel actions.
The Application Collection unlocks the source for every Application block. All Access unlocks every Collection.
Already purchased? Log in
Oauth Consent Blueprint is the grant screen Acme shows when connecting to GitHub, rendered as a static blueprint with a scrim background. The card names exactly two scopes: repo:read (lists repos and commits, cannot read file contents) and statuses:write (posts deploy checks to pull requests, cannot push code). A connecting-as row shows Avery Stone with avery@acme.com and the acme-org name. Four items in a cannot list draw a hard boundary. Authorize and Cancel sit at the bottom.
Permissions and the not-granted list are const arrays. Every sentence says what the scope does and what it cannot do; the cannot list is as important as the granted list because it is the question users are silently asking.
Reach for this block on the OAuth redirect page users land on when they click Connect to GitHub or a similar first- party integration trigger. Wire Authorize to your token exchange endpoint and Cancel to the previous settings page.
A natural flow around it on an Application Pro page:
Before
After
One strong use is the GitHub OAuth grant screen. Other consent blueprints:
Tip: the cannot list is not legal boilerplate; it is the fastest way to answer the question users always have before they click Authorize.