Learn about persistent grant data stores and persistent authorizations.
PingFederate uses a built-in HSQLDB 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 may cause various problems due to its limitations and HSQLDB involved cases are not supported by PingIdentity.
Persistent authorizations include those obtained by OAuth clients in the following ways:
- Grants obtained or updated using the authorization code, resource owner credentials,
or device authorization grant type, in conjunction with the refresh token grant typeNote:
If the use cases involve mapping attributes from authentication sources, such as IdP adapter instances or IdP connections, or password credential validator (PCV) instances to the access tokens, directly or through persistent grant-extended attributes, storing these attributes from authentication sources and their values along with the persistent grants maintains them for reuse when clients subsequently present refresh tokens for new access tokens.
- Grants obtained or updated by using the implicit grant type, for which PingFederate
is configured to reuse existing persistent grantsNote:
If the use cases involve mapping attributes from authentication sources or PCV instances to the access tokens, runtime procedures obtain attribute values for each token request, but persistent grants do not store with attributes or their values.
Persistent grants and any associated attributes and their values remain valid until the grants expire or until PingFederate explicitly revokes or cleans them up.
Attribute values are always stored encrypted when a directory is used. If a database server is used (including the built-in HSQLDB database), attribute values are also stored encrypted by default.