Custom scopes
Resources are the protected endpoints that applications request access to using OAuth 2 authorization services. The PingOne platform includes two predefined resources, PingOne API, which is a defined resource that represents the PingOne APIs, and openid, which represents OpenID Connect scopes. These resources have self scopes that grant an actor permission to perform CRUD operations on the actor’s data (such as p1:create:device, p1:read:device, p1:update:device, and p1:delete:device).
In addition, the platform lets you configure additional resources and their associated self scopes. For example, a custom resource such as https://api.acme-photo.com might have upload:photos, read:photos, edit:photos, and delete:photos scopes that give users permission to manage their photo libraries.
PingOne supports the following two types of resource scopes.
Custom resource scopes
Custom resource scopes are associated with protected endpoints on a non-PingOne resource server. Custom resources can be associated with an application either exclusively, or in addition to the platform’s predefined resources. When an application is associated with both the PingOne platform resource and a custom resource, an authorization request cannot include scopes from both PingOne and the custom resource.
If you do specify scopes from both PingOne and the custom resource in the authorize request, the request returns the following error:
The request could not be completed. One or more validation errors were in the request.: May not request scopes for multiple resources (Correlation ID: 8E7B23B8-6761-4532-8AFC-4B723D52FF5D).OIDC-based applications in PingOne can now request an access token that accesses scopes from multiple custom resources in a single request. This capability simplifies the application authentication and authorization process and reduces the number of requests an application must make. By default, if more than one resource is associated with the application, actors need to make separate authorization requests to get a token for the desired resource scopes. However, if the requestScopesForMultipleResourcesEnabled OIDC property on the application is set to true, then the application accepts scopes from multiple custom resources, eliminating the need to make multiple authorize requests.
For more information, refer to Applications OIDC settings data model, Resource Scopes, and Create scope in the PingOne Platform API Reference.
Custom PingOne API scopes
Custom PingOne API scopes control access to specific user schema attributes. As described above, a PingOne platform custom scope is based on an existing platform scope and uses the schemaAttributes property in the scope’s definition to list the specific user attributes that the end user has permission to read or update. For example, a scope that grants permission to update only the user’s email address would list only the email attribute in the schemaAttributes property. This PingOne custom scope is named by adding a descriptive suffix to the base PingOne scope name: p1:update:user:email-only.
For more information about defining custom PingOne API scopes, refer to Create PingOne access control scope in the PingOne Platform API Reference.