Resource scopes

The PingOne platform includes two native resources:

PingOne API represents the APIs with several predefined self-management scopes that grant users access to PingOne resources.
OpenID Connect (OIDC) represents OIDC scopes and controls which user details the application can access during authentication.

PingOne self-management scopes

The PingOne API native resource has predefined self-management scopes that grant users access to PingOne resources and are only applicable to users. The self-management scopes included in an authorization request identify the resources the end user can access to perform self-management actions, such as modifying their own user attributes or enabling multi-factor authentication (MFA) for their own user identity. Learn more in PingOne self-management scopes in the PingOne API documentation.

OIDC scopes

OIDC scopes are used by an application during authentication to authorize access to user details, such as name and email address. Each scope returns a set of user attributes, called claims.

You can define custom attributes for OIDC resources and change the way they’re delivered to the application, such as through an ID token, the UserInfo endpoint, or both. Learn more in OIDC scopes in the PingOne API documentation.

Changes made to the OpenID Connect resource define the global configuration, which is inherited by applications. Applications can override the inherited global attributes with custom attributes. Learn more in Customizing OIDC attributes for an application.

Scope combinations and restrictions

You can use PingOne to define custom resources and their associated scopes. Custom resources can be associated with an application either exclusively or in addition to the native resources.

You can’t include scopes from both the PingOne API resource and a custom resource in the same authorization request. However, you can include scopes from both the OIDC resource and a custom resource in the same request.

Learn more about authorization request outcomes based on the combination of allowed scopes in Scope configuration scenarios and outcomes and Resource Scopes in the PingOne API documentation.

You can enable an OIDC-based application to request scopes from multiple resources in a single request. Learn more about the Request scopes to access multiple resources option in Editing an application - OIDC.

Learn more about obtaining unique access tokens for each API resource in OAuth access token usage strategies for multiple resources on the Ping Identity blog.

Scope configuration scenarios and outcomes

Depending on the allowed scopes configured on the application’s Resources tab, PingOne handles authorization requests differently. The following table outlines the possible configuration scenarios and expected outcomes depending on what scopes are explicitly requested:

Allowed scopes Outcome

Allowed scopes	Outcome
`openid`	(Default scenario) The `openid` OIDC scope is always allowed. An authorization request can explicitly ask for the `openid` scope. If the scope parameter is omitted, PingOne assumes the authorization request wants all the allowed scopes. Given this configuration, the requested scope defaults to `openid`.
`openid` One or more scopes from the OIDC native resource	The application is only allowed to ask for OIDC scopes. An authorization request can ask for any combination of the allowed scopes. If the scope parameter is omitted, PingOne assumes the request wants all allowed scopes, returning `openid` and all OIDC scopes added to the application.
`openid` One or more scopes from the OIDC native resource One or more self-management scopes from the PingOne API native resource	An authorization request can ask for any combination of the allowed scopes. If the scope parameter is omitted, PingOne assumes all allowed scopes are wanted, returning `openid` and all OIDC scopes and self-management scopes added to the application.
`openid` One or more scopes from the OIDC native resource One or more scopes from one or more custom resources	If the application is allowed to ask for scopes from multiple custom resources: The request can ask for any combination of the allowed scopes. If the scope parameter is omitted, PingOne assumes all allowed scopes are wanted, returning `openid` and all OIDC scopes and custom resource scopes added to the application. If the application isn’t allowed to ask for scopes from multiple custom resources, the outcome varies depending on the authorization request. Valid requests include: Any OIDC scopes alone. A single custom resource scope (with or without OIDC scopes). Multiple custom resource scopes belonging to the same custom resource (with or without OIDC scopes). If the scope parameter is omitted from the authorization request, PingOne attempts to request all allowed scopes, and the request will fail with the following error: `May not request scopes for multiple custom resources`.
`openid` One or more scopes from the OIDC native resource One or more self-management scopes from the PingOne API native resource One or more scopes from one or more custom resources	The outcome varies depending on the authorization request’s specific parameters. However, the restrictions and fallback behaviors outlined in the previous scenario apply to this scenario.

openid

(Default scenario) The openid OIDC scope is always allowed.

An authorization request can explicitly ask for the openid scope. If the scope parameter is omitted, PingOne assumes the authorization request wants all the allowed scopes. Given this configuration, the requested scope defaults to openid.

openid
One or more scopes from the OIDC native resource

The application is only allowed to ask for OIDC scopes.

An authorization request can ask for any combination of the allowed scopes. If the scope parameter is omitted, PingOne assumes the request wants all allowed scopes, returning openid and all OIDC scopes added to the application.

openid
One or more scopes from the OIDC native resource
One or more self-management scopes from the PingOne API native resource

An authorization request can ask for any combination of the allowed scopes.

If the scope parameter is omitted, PingOne assumes all allowed scopes are wanted, returning openid and all OIDC scopes and self-management scopes added to the application.

openid
One or more scopes from the OIDC native resource
One or more scopes from one or more custom resources

If the application is allowed to ask for scopes from multiple custom resources:

The request can ask for any combination of the allowed scopes.
If the scope parameter is omitted, PingOne assumes all allowed scopes are wanted, returning openid and all OIDC scopes and custom resource scopes added to the application.

If the application isn’t allowed to ask for scopes from multiple custom resources, the outcome varies depending on the authorization request. Valid requests include:

Any OIDC scopes alone.
A single custom resource scope (with or without OIDC scopes).
Multiple custom resource scopes belonging to the same custom resource (with or without OIDC scopes).

If the scope parameter is omitted from the authorization request, PingOne attempts to request all allowed scopes, and the request will fail with the following error: May not request scopes for multiple custom resources.

openid
One or more scopes from the OIDC native resource
One or more self-management scopes from the PingOne API native resource
One or more scopes from one or more custom resources

The outcome varies depending on the authorization request’s specific parameters. However, the restrictions and fallback behaviors outlined in the previous scenario apply to this scenario.