PingOne access tokens are signed JWTs (JSON Web Tokens) that include identity claims about and attributes of the requestor, usually a user identity. The resource attributes service lets you customize the content of access tokens by adding custom attributes and their values. This is a great way to convey additional information about the user to applications. Custom attributes have a cumulative length constraint of 16 Kb. See Custom attributes in Schemas for more information.

Resource attributes are essentially custom identity claims associated with a resource. For example, suppose the clothing.preferences resource with scope sizes provides “clothing size” user claims in the token. By default, the sizes scope does not include a t-shirt size user claim. To include the user.tshirtSize user attribute as a user claim in the token, a resource attribute entity can be created that associates the tshirtSize attribute with the clothing.preferences resource. Then, for token requests to clothing.preferences with scope sizes, the tshirtSize user claim is included in the token. If the attribute is multiValued, then the claim will be an array of values. The following diagram shows the workflow:

Resource attributes

For information about an access token’s core claims, see Access token claims. A token’s core identity claims cannot be modified or deleted.

Resource attributes data model

Property Description
name A string that specifies the name of the custom resource attribute to be included in the access token. The following names are reserved and cannot be used:
  • acr
  • amr
  • aud
  • auth_time
  • client_id
  • env
  • exp
  • iat
  • iss
  • jti
  • org
  • p1.* (any name staring with the p1. prefix)
  • scope
  • sid
  • sub
type A string that specifies the type of resource attribute. Options are:
  • CORE: The claim is required and cannot not be removed.
  • CUSTOM: The claim is not a CORE attribute. All created attributes are of this type.
value A string that specifies the value of the custom resource attribute. This value can be a placeholder that references an attribute in the user schema, expressed as “${user.path.to.value}”, or it can be a static string. Placeholders must be valid, enabled attributes in the environment’s user schema. Examples fo valid values are: “${user.email}”, “${user.name.family}”, and “myClaimValueString”.

Response codes

Code Message
200 Successful operation.
201 Successfully created.
204 Successfully removed. No content.
400 The request could not be completed.
401 You do not have access to this resource.
404 The requested resource was not found.