Grant storage and management
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 Ping Identity. |
Persistent grants and any associated attributes and their values remain valid until the grants expire or until PingFederate explicitly revokes 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. Depending on the datastore being used, the removal of expired grants can be done by the datastore itself. You should configure the datastore to purge expired grants whenever possible. 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.