WebSphere® Application Server OAuth support provides two options for OAuth token and client persistence: in-memory and database.
For in-memory clients and tokens, the clients are persisted to the file system and tokens remain in memory. MBean interfaces are available to add or remove clients, which synchronize changes in a cluster and persist the changes to the file system. Tokens are managed by using dynamic cache objects or local in-memory hashmaps if no dynamic cache is specified.
In the database implementation, dynamic cache objects are also used to back the database persistence for both the client table and the token table. Typically the cache that backs the database is a weak hashmap based on a least-recently-used policy. Data in the caches are used if found, which avoids database queries for commonly used data and increases performance. If no dynamic cache is specified for the database, a local in-memory hashmap is used instead.
For OAuth environments that are not clustered, dynamic cache configuration is not required.
Dynamic cache objects are highly configurable and tunable to maximize performance. By default, the OAuth service creates dynamic cache instances with reasonable default values in most environments.
cache.instance.0=/services/cache/OAuth20MemTokenCache cache.instance.0.cacheSize=1000 cache.instance.0.enableDiskOffload=true cache.instance.0.flushToDiskOnStop=true cache.instance.0.useListenerContext=false cache.instance.0.enableCacheReplication=true cache.instance.0.replicationDomain=DynaCacheCluster cache.instance.1=/services/cache/OAuth20MemTokenOwnerCache cache.instance.1.cacheSize=1000 cache.instance.1.enableDiskOffload=true cache.instance.1.flushToDiskOnStop=true cache.instance.1.useListenerContext=false cache.instance.1.enableCacheReplication=true cache.instance.1.replicationDomain=DynaCacheCluster
cache.instance.2=/services/cache/OAuth20DBTokenCache cache.instance.2.cacheSize=1000 cache.instance.2.enableDiskOffload=false cache.instance.2.flushToDiskOnStop=false cache.instance.2.useListenerContext=false cache.instance.2.enableCacheReplication=true cache.instance.2.replicationDomain=DynaCacheCluster cache.instance.3=/services/cache/OAuth20DBClientCache cache.instance.3.cacheSize=1000 cache.instance.3.enableDiskOffload=false cache.instance.3.flushToDiskOnStop=false cache.instance.3.useListenerContext=false cache.instance.3.enableCacheReplication=true cache.instance.3.replicationDomain=DynaCacheCluster
In order for these caches to be correctly used in a cluster, the cluster nodes must be configured to use a replication domain named DynaCacheCluster. No additional configuration is required beyond setting the replication domain.
Only one replication domain can be specified per node. Any cluster nodes that already have a replication domain configured require advanced configuration to create dynamic cache objects for the existing replication domain. Environments that use tuned dynamic cache objects, for example to expand the cache size, must also use the advanced configuration.
oauth20.token.cache.jndi.tokensand
oauth20.token.cache.jndi.users
oauth20.db.token.cache.jndi.tokensand
oauth20.db.token.cache.jndi.clients
If the dynamic cache objects are improperly configured, they are replaced with local in-memory hashmaps. The hashmaps provide a performance boost, but the data is not replicated across nodes in a cluster. This becomes important for cache invalidation. For example, users that revoke their OAuth tokens in an improperly configured environment can still have access by using their OAuth tokens on other nodes, until the token expires.
Environments that do not allow token revocation, or environments that can accommodate token inconsistency for the duration of the token lifespan, also have the option of disabling dynamic caching or cache invalidation. Disabling dynamic caching results in further increased performance at the cost of the longer access window.