Token refresh fails in case of multiple invocations of the edrs-api.

[lholthof]

In the BPDM scenario multiple Business Partners are uploaded simultaneously by independent external processes using the edc’s erds-api. This leads to the situation that we have multiple calls to the erds-api for the same edrs. Our use-case uses the option auto_refresh=true for those calls. The first call succeeds without issues, but the second call fails, due to the “old” access_token/refresh_token being overwritten by DataPlaneTokenRefreshServiceImpl.

I would like to suggest a solution for this which ensures one connector is only triggering once the token refresh. Basically this could be achieved by a lock for this edrs. Would the lease table be suitable to be reused to represent such a lock?

The second call would not trigger a token refresh. What would be a suitable behavior of the API?

1. Wait for the refresh of the other call, which would delay the response
2. Put a response to indication temporary unavailability and a retry_after

In addition to the current issue with the BPMN use case where we identified this behaviour, the oauth2 refresh_token grant-type usually mandates that the client must not use the same credentials more than once for a token refresh as this could indicate an attack (which was also considered when writing the spec).