Scopes and consent

A scope is a unit of what an application can learn about a user:

Scope	Gives
openid	The ability to sign in at all, with the user's stable identifier.
profile	Display name and basic profile.
email	The user's email address.
address, phone	Postal address and phone number.
offline_access	The ability to stay signed in; this is what gives refresh tokens.
elpan:identities	The addresses the user can send as.

Scope policies

Scopes aren't a plain on/off list. Each application has a scope policy per scope:

Policy	Meaning
Mandatory	Always granted. The application can depend on it.
Default	Pre-selected on the consent screen. The user can remove it.
Optional	Offered on the consent screen. The user can add it.
Prohibited	Never granted, whatever the application asks for.

A new application starts with openid, profile, and email mandatory, offline_access optional, and everything else prohibited.

Treat offline_access with care

A refresh token is access that outlives the browser session. Grant more than the default only to an application that needs it.

"The requested scope is not allowed"

The application asked for something you prohibited. Check this policy.

Consent

The first time an application asks for access, the user sees a consent screen. It names the application with the name, publisher, and logo you registered, lists the permissions, and offers allow and cancel.

• Allow sends the user back to the application, signed in.
• Cancel also sends the user back, with the access_denied error, so the application can show its own sign-in page again. No consent is recorded.
• Sign in as another user, next to the user's address, signs them out and opens the sign-in page for the same application. The next user is asked for consent, and the application gets that user.

The decision is remembered, so the second sign-in asks nothing. An application that sends prompt=consent gets the consent screen every time; so does one that sends prompt=select_account, so the user can switch accounts.

The request survives the sign-in

The provider keeps the application's request for 30 minutes. A user can sign out, sign in as someone else, complete a second factor, or set one up, and still land on that application's consent screen, not the portal.

You can revoke the decision in three places:

Revoked by	Where
The user	Connected Apps in their portal.
You	The user's panel page.
For one session	The provider's Sessions tab. It shows the live sign-ins per application, each of which you can revoke.

Revocation is central too

Because the sign-in is central, so is removing access. Disable the user in the panel and every application using the provider loses them at once, with no per-application cleanup.