SSO: ID Token should be used in place of the Access Token in the OIDC authentication step

[gbarbon]

Describe the bug
The OpenID Connect (OIDC) Access Token is currently used for authenticating the user with the SSO. However, with some OIDC providers the authentication process fails during the token validation. This is due to the fact that some providers do not include some claims in the Access Token.

This is actually correct, since the official OIDC specification does not define any claims for the Access Token, while it does that for the ID Token. Moreover, the Access Token should be only a simple string (see below for further information). Thus, we should retrieve the information corresponding to those claims form the ID Token.

To Reproduce
Try to authenticate using an OpenID Connect provider that does not provide 'aud', 'iat' or 'sub' claims in the access token. The authentication process will fail in the token validation step, because the required claims are not found.

Expected behavior
The ID Token, wich we already obtain from the OIDC provider, should be used in place of the Access Token. In this way the token validation would be fine.

Screenshots
n/a

Version of Kapua
1.5.0-SNAPSHOT

Type of deployment
[ ] Local Vagrant deployment
[ ] Docker
[ ] Openshift (in its variants)
[x] Others (all)

Main component affected
[x] Console (in case of console please report info on which browser you encountered the problem)
[ ] REST API
[ ] Message Broker
[ ] - Others

Additional context
The Access Token used in OIDC (see here for the official OIDC specification) is defined in OAuth 2 (since OIDC is defined on top of OAuth 2), see here, and no claims are defined in it. Moreover, note that here the spec says: An access token is a string representing an authorization issued to the client. The string is usually opaque to the client.

The current SSO implementation in Kapua is using the Access Token in order to retrieve the 'sub' string, but in the official specification the 'sub' claim is not required to be in this token (even if it's often included by various providers, e.g. Keycloak). Thus it would be better to rely on the ID Token instead.