[BUG] Missing validation of OIDC tokens

[FBasels]

1. Summary - Tokens are not validated in any way during agent authentication. Thus, a service accept access tokens that are issued for another service.

2. Bug Details - A detailed explanation of the issue, structured in subsections:

   1. What? - Tokens from the OIDC provider are not validated, when authenticating an agent
   2. Where? - AuthenticationManager in the las2peer webconnector
   3. When?/How often? -
   4. How?/Current state - As far as I can see the token is only "validated" during the agent authentication (by requesting the userinfo from the OIDC provider) if the agent does not exist at the moment . However it is never checked if the token was issued to this service and not to a different one.

[ThoreKr]

Ideally it would honor the audience and authorized party and check if these match the given configuration.

This would require the client id to be known to the authentication manager.

[FBasels]

But these steps are done with the ID token, currently the authenticationManager uses the access token. Correct me if I am missing something, but if we have the ID token, we do not need the access token here anymore, since it is only used to send a request to the /userinfo endpoint. These information are already given in the ID token.

[ThoreKr]

This is probably blurred, due to the way the authentication is currently botched up. Before the switch to basic auth the token is used for authentication without further validation.

If you look at the tokens sent by cae or requirements bazaar these are also id tokens.

However, if i understood correctly, the token is nothing more than a weird way of prefilling a registration form, Is - this strictly speaking - authentication or authorization?

[FBasels]

As you said, the token is used for getting the preferred_username of the user and use it as username for the UserAgent. So you could say it is used for authentication, not authorization, but only in the case a UserAgent could not be found with the credentials that were send in the request. So if a user already exist/a user could be found with the credentials, the token is not used at all. So we only have to have a look at the creation of a new UserAgent with the tokens, or am I missing something?

To verify the token, the authenticationManager (or the Webconnector in general) would need to know the clientIds of the services that sends the request. It would not make sense if the service would send the id within the request as header or something.

[ThoreKr]

Hm. Probably it doesn't make sense to tackle this right now.

It is a security issue in 0.7 (which is still used by reqbaz prod), and technically currently is, but the authentication right now is anything but secure anyways (probably that claim should be removed from the website).

It would not make sense if the service would send the id within the request as header or something.

Technically this information is included in the token (aud claim), even the issuer header is unnessesary, since there is an iss claim.

Maybe the best way forward is to close this in favour of #96 and #95. and add the supported audiences to the configuration parameters or in the application registration and do validation from there.