Add option to save access tokens on database or not

[enricovianello]

This PR introduces the feature of not storing access tokens on database. The feature has been added as a configurable option:

iam.access_token.store_on_database = false

Default value is false to preserve the original behavior of storing access token on database and let administrators to turn it on. The refresh-tokens are not affected by this changes and are still persisted on database

The effects of this feature turned on are:

• scopes will be always included in access-tokens and registration-access-tokens
• client_id has been added to registration-access-tokens
• registration-access-tokens are still persisted on database
• using an access-token to authenticate to IAM's APIs, to validate it, a set of validation steps are done:
  1. the signature is verified
  2. the issuer is checked to be the one configured
  3. the token expiration is evaluated
  4. the presence of claim client_id is verified and that client must be enabled
  5. if token subject differs from client_id value, the presence of the user identified by the subject is verified. Also user's status must be active and its email verification must be. If one AUP is defined, user's signature is checked too.
• a new database table is used to support access token revocation, persisting the hash of the token and the expiration info. This table is cleaned up by the garbage collector mechanism.

This PR also includes a relevant change on codebase related to the usage of a Clock inside both services and unit tests. All the new Date() and similar have been migrated. This allowed an enhancement about testing token expired behaviors.

This PR introduces the setting of UTC as the timezone used to connect to database and store data. Conversions to the local time zone is done through the database connector.

This PR also introduces the ShedLock logic to manage concurrency on deleting entries from database (during garbage collector operations).

This PR changes the response got during Token Exchange when an expired/malformed subject token is used: the error has been changed, aligning it to the specification, from invalid_token to invalid_grant and HTTP code has become 400 instead of 401.

[giacomini]

Even if iam.access_token.store_on_database = true we should avoid to save the full token (i.e. payload + signature) in the DB, so that the tokens are not immediately usable if stolen.

[federicaagostini]

Even if iam.access_token.store_on_database = true we should avoid to save the full token (i.e. payload + signature) in the DB, so that the tokens are not immediately usable if stolen.

This is related to issue #1158.

[sonarqubecloud]

Quality Gate passed

Issues
7 New issues
16 Accepted issues

Measures
3 Security Hotspots
90.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud