Consent screen / scopes
The 'this app wants to access your...' page, and the named permissions (scopes) it is asking you to approve.
See it
What it is
Scopes are the named permissions an app requests, strings like 'read:user', 'repo', or 'calendar.events.readonly'. The consent screen is the page the authorization server shows the user during OAuth, listing those scopes in human words and asking allow or deny. That server is often also an identity provider, but the roles are separate: 'identity provider' is the OIDC term for the thing that authenticates a person, while consent belongs to whoever issues the token. Whatever the user approves gets baked into the issued token, and your API is expected to check it on every call.
Design it around the smallest set that makes the feature work. Ask only for what today's action needs, and request the rest later with incremental authorization, because a wall of scary permissions at first click is one of the great conversion killers. Read-only variants exist for a reason: 'calendar.readonly' converts far better than full calendar write access.
Two traps. Users skim, so the copy on the screen is security UI, not decoration: 'See, edit, and permanently delete all your files' is honest in a way 'Manage Drive' is not. And granting is not one-way. People revoke access from their provider's account page, and your integration will start getting 401s or invalid_grant with no warning, so handle revocation as a normal state and prompt for reconnect instead of silently failing forever.
Ask AI for it
Set this app up as an OAuth client of [provider] with least-privilege scopes. In the provider's console, configure the app name, logo, support and privacy policy URLs, and the exact redirect URIs. You do not invent scopes here and you do not build the consent screen: the provider owns both. Map each feature in this app to the provider's existing scopes, list them with a plain-language description written from the user's point of view, and request the minimum set at the moment the feature actually needs it, using incremental authorization for the rest. Explain what you are about to ask for on your own screen before redirecting. Handle a denial as a normal outcome rather than an error page, persist the granted scope set with the token, enforce it in API middleware, and treat a later revocation as a reconnect prompt. If this project is itself the authorization server, say so explicitly before defining custom scopes in verb:resource form (read:profile, write:documents) and building your own consent UI with real Allow and Deny buttons.