Consent
Who gets asked, when, and how a consent is withdrawn.
Your org owns its users' accounts: the brand's own apps never ask anyone for consent. An app marked first_party gets what it asks for as soon as the person signs in, and signs them in to the brand's other apps without asking again. You manage your users through the management API without asking them anything.
The consent page is for apps that aren't yours: an MCP host such as Claude or Cursor, an agent, or an app that registered itself with the issuer. They can reach only the APIs you opened to apps that aren't yours (allow_third_party, off by default), and the person they act for decides what they may do.
What the person sees
The consent page, in the brand's look, shows the app's name (and that it registered itself, when it did), each scope it asks for in the words your API registered, where allowing sends them, and the app's own privacy policy and terms. They allow or refuse.
Remembered consents
What a person allows an app is remembered, per person and app, and only grows: their next sign-in to it, in any browser, asks only for what they never allowed. Two exceptions are asked every time: a native app, since anything on the device could claim its redirect URI, and a request with prompt=consent.
A consent only ever grants what the app may still have: dropping a scope from an API, deleting an API or closing it to apps that aren't yours takes that from every consent, and defining the scope again asks people again.
Withdrawing a consent
- The person sees and withdraws theirs through the account API, from one of the brand's own apps.
- The tenant sees and withdraws a user's through the management API.
Withdrawing ends everything the app has for the person (every grant, offline ones included, with their tokens), tells each session it was signed in to over the back channel, and records user.consent_revoked. Their next sign-in to it asks again.