PingFederate uses a built-in HSQLDB database as its persistent grant datastore after the initial setup.
Use the built-in HSQLDB only for trial or training environments. For testing and production environments, always use a secured external storage solution for proper functioning in a clustered environment.
Testing involving HSQLDB is not a valid test. In both testing and production, it might cause various problems due to its limitations and HSQLDB involved cases are not supported by PingIdentity.
Persistent grants, and any associated attributes and their values, remain valid until the grants expire or until PingFederate explicitly revokes them or cleans them up.
PingFederate removes expired grants and the associated attributes from the grant datastore once a day. The frequency and the size of the cleanup batch are configurable. Optionally, PingFederate caps the number of persistent grants on a basis of the combination of user, client, and grant type.
For revocation, PingFederate provides two endpoints.
- Token revocation endpoint
- The token revocation endpoint allows clients to notify the authorization server that they no longer need a previously-obtained refresh or access token. The revocation request invalidates the actual token and possibly other tokens based on the same authorization grant.
- Grant-management endpoint
- The grant-management endpoint allows resource owners to view and optionally revoke the persistent access grants they have authorized.
Intended for OAuth clients, the token revocation endpoint is the endpoint to which clients send their token revocation requests. The grant-management endpoint is for resource owners. It displays a list of grants the resource owners have made. Resource owners can view and optionally revoke one or more grants as they see fit.