OpenID Connect Scopes


OpenID Connect OAuth Clients use OAuth Scope values, as defined in OAuth 2.0 RFC 6749, to specify what access Privileges are being requested for Access Tokens.

The scopes associated with Access Tokens determine what resources will be available when they are used to access OAuth 2.0 protected endpoints. Protected Resource endpoints MAY perform different actions and return different information based on the scope values and other parameters used when requesting the presented Access Token.

For OpenID Connect, scopes can be used to request that specific sets of information be made available as Claim Values.

Claims requested by the following scopes are treated by Authorization Servers as Voluntary Claims.

OpenID Connect defines the following OpenID Connect Scopes values:

Multiple OpenID Connect Scopes values MAY be used by creating a space-delimited, case-sensitive list of ASCII OpenID Connect Scopes values.

The Claims requested by the profile, email, address, and phone scope values are returned from the Userinfo_endpoint, as described in Section 2.3.2.

The Claims requested by the profile, email, address, and phone scope values are returned from the Userinfo_endpoint, as described in Section 5.3.2 of OAuth 2.0 RFC 6749, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the Identity Token.

Standard Claims#

OpenID Connect has defined some Standard Claims.


The Openid-configuration Endpoint for the Authorization Server provides a list of "scopes_supported". The OAuth Client can query the Openid-configuration Endpoint and obtain this list and then query the Userinfo_endpoint to obtain values for the Entity within the Identity Token.

The OpenID Connect Scopes that the OAuth Client requested are OPTIONALLY presented in a UI with wording similar to: "Do you authorize them to do this on your behalf". The OAuth Client may request certain rights, but the Resource Owner may only grant some of them or allow others that are not even requested. Such a page may not be presented to the Resource Owner, however as when the Resource Owner has already granted the client such rights by way of a EULA, employment contract, etc. and this page maybe skipped.

What is in the OpenID Connect Scopes, how you use them, how they are displayed or not displayed, and pretty much everything else to do with scopes are not defined by the OAuth spec. They may be specified within User Managed Access profiles or OpenID Connect does define a few OpenID Connect Scopes. In some cases, the End-User will be given the option to have the OpenID Provider decline to provide some or all information requested by Relying Party. To minimize the amount of information that the End-User is being asked to disclose, an Relying Party can elect to only request a subset of the information available from the Userinfo_endpoint.

Example OpenID Connect Scopes Request#

The following is a non-normative example of an unencoded scope request:
scope=openid profile email phone

More Information#

There might be more information for this subject on one of the following: