OIDC legacy token (in)compatibilities

1. V1-V2 Authorization code without consent

Uncaught runtime exception in the logs. Response for the client:

{"error_description":"RuntimeException","error":"invalid_request"}

2. V1-V2 Authorization code with consent

(no claim-values encoded in code)

Uncaught runtime exception in the logs. Response for the client:

{"error_description":"RuntimeException","error":"invalid_request"}

Produces tokens acting in the same way as case 5.

3. V1-V2 Authorization code with consent

(claim-values encoded in code)

Uncaught runtime exception in the logs. Response for the client:

{"error_description":"RuntimeException","error":"invalid_request"}

Produces tokens acting in the same way as case 6.

4. V1-V2 Refresh/Access tokens without consent

Uncaught runtime exception in the logs. Response for the client:

{"error_description":"RuntimeException","error":"invalid_request"}

5. V1-V2 Refresh/Access tokens with consent

(no claim-values encoded in token)

Uncaught runtime exception in the logs. Response for the client:

{"error_description":"RuntimeException","error":"invalid_request"}

Only claims with name matching the attributeID are returned

See JOIDC-19: Applying consent to back-channel uses the wrong attribute namesClosed

6. V1-V2 Refresh/Access tokens with consent

(claim-values encoded in token)

Uncaught runtime exception in the logs. Response for the client:

{"error_description":"RuntimeException","error":"invalid_request"}

The consented claims whose values are encoded (setToToken=”true” on V1/V2 attribute-encoder configuration) in the tokens are returned