--- title: Resource scopes description: You can use PingOne to define custom resources and their associated scopes. component: pingone page_id: pingone:applications:p1_resource_scopes canonical_url: https://docs.pingidentity.com/pingone/applications/p1_resource_scopes.html revdate: January 9, 2023 section_ids: pingone-self-management-scopes: PingOne self-management scopes oidc-scopes: OIDC scopes scope-combinations-and-restrictions: Scope combinations and restrictions p1_scope_configuration: Scope configuration scenarios and outcomes --- # 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](https://developer.pingidentity.com/pingone-api/foundations/pingone-roles-scopes-and-permissions/access-services-through-scopes-and-roles/pingone-self-management-scopes.html) 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](https://developer.pingidentity.com/pingone-api/foundations/pingone-roles-scopes-and-permissions/access-services-through-scopes-and-roles/openid-connect-oidc-scopes.html) 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](p1_customizing_oidc_attributes_for_application.html). | ## 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](#p1_scope_configuration) and [Resource Scopes](https://developer.pingidentity.com/pingone-api/platform/resources/resource-scopes.html) 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](p1_edit_application_oidc.html). Learn more about obtaining unique access tokens for each API resource in [OAuth access token usage strategies for multiple resources](https://www.pingidentity.com/en/company/blog/posts/2019/oauth-2-access-token-usage-strategies-multiple-resources-apis-pt-3.html) 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 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `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. |