At the moment, the server will allow any number of client connections and they can all use the same key concurrently. This is great for keys stored in the database, but for keys that are inside an HSM might have limits associated with concurrent access.
For example, the YubiHSM2 documents that "On a single YubiHSM 2 it is possible to establish up to 16 independent and concurrent Sessions. Note that while multiple concurrent Sessions can be active at a given time, the device still serves as a rendezvous point. This means that time-consuming operations such as generating a long RSA key will block commands in other Sessions."
The database should grow a nullable field on the token table that lets admins limit the number of active signatures for that token (which may have multiple keys in it). It should be fine having more than that limit of connections using the keys, it just needs to throttle each sign request.
At the moment, the server will allow any number of client connections and they can all use the same key concurrently. This is great for keys stored in the database, but for keys that are inside an HSM might have limits associated with concurrent access.
For example, the YubiHSM2 documents that "On a single YubiHSM 2 it is possible to establish up to 16 independent and concurrent Sessions. Note that while multiple concurrent Sessions can be active at a given time, the device still serves as a rendezvous point. This means that time-consuming operations such as generating a long RSA key will block commands in other Sessions."
The database should grow a nullable field on the token table that lets admins limit the number of active signatures for that token (which may have multiple keys in it). It should be fine having more than that limit of connections using the keys, it just needs to throttle each sign request.