EDR token refresh implementation is inconsistent and deviates from the documentation

[Sebastian-Wurm]

Describe the bug

On API consumer side, the method TokenRefreshHandlerImpl.createTokenRefreshRequest() adds the "Content-Type" header "application/x-www-form-urlencoded" to the token refresh request, but adds the parameters "grant_type" and "refresh_token" as query parameters of the URL rather than as urlencoded body.

On API provider side, the method TokenRefreshApiController.refreshToken() also adds the parameters as query parameters.

The corresponding documention correctly adds these parameters as urlencoded body in the HTTP request.

To Reproduce

Adding the "Content-Type" header "application/x-www-form-urlencoded", which describes the format of the HTTP body, and providing a zero-length HTTP body is inconsistent. The implementation also deviates from the documentation. Additionally, this leads to an incompatibility between EDC 0.7.2 and 0.7.3 when refreshing the EDR token, which is why we found this issue.

Expected behavior

Either send/receive the parameters as urlencoded body or remove the "Content-Type" header "application/x-www-form-urlencoded" and adapt the documentation. As tokens tend to be long and different environments may have different restrictions regarding URL length, it's probably the better idea to urlencode the parameters in the body as defined in the documentation.

Screenshots/Error Messages

N/A

Context Information

• Used version: EDC 0.7.2 and 0.7.3 (but seems still to be on main, too)

Please be aware, that fixing this according to either of the proposals mentioned as expected behavior again breaks the EDR token refresh. So, best is to keep this as a known issue until the first major release of Tractus-X EDC.

Possible Implementation

Use URLEncoder.

[github-actions]

This issue is stale because it has been open for 4 weeks with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[Sebastian-Wurm]

@ndr-brt : Thanks for reopening.

[ndr-brt]

Additionally, this leads to an incompatibility between EDC 0.7.2 and 0.7.3 when refreshing the EDR token, which is why we found this issue.

could your report the error you are getting? like status code/response message/stacktraces?

[Sebastian-Wurm]

Additionally, this leads to an incompatibility between EDC 0.7.2 and 0.7.3 when refreshing the EDR token, which is why we found this issue.

could your report the error you are getting? like status code/response message/stacktraces?

HTTP error 415 unsupported media type is returned on

1. calling data address endpoint with auto-refresh=true if EDR is expired. 415 error is wrapped into a 400 error on consumer side.
2. calling the EDRs API refresh endpoint

(1.)
{
"servlet": "EDC-management",
"message": "Unsupported Media Type",
"url": "/api/management/v2/edrs/b07de376-c5a4-4115-a5cf-4ab309a88e76/refresh",
"status": "415"
}

(2.)
[
{
"message": "Unsupported Media Type",
"type": "InvalidRequest",
"path": null,
"invalidValue": null
}
]

[wolf4ood]

I think there are two issue here.

One is the unsupported media type which was fixed in 0.7.3.
If the consumer is using 0.7.2 we cannot do much as the issue arose also with 0.7.2 vs 0.7.2.

The other issue is to use form body instead of query params which is a breaking change if we suddenly switch
to form body.

If we want to solve this we should guarantee backward compatibility

[Sebastian-Wurm]

I think there are two issue here.

One is the unsupported media type which was fixed in 0.7.3. If the consumer is using 0.7.2 we cannot do much as the issue arose also with 0.7.2 vs 0.7.2.

The other issue is to use form body instead of query params which is a breaking change if we suddenly switch to form body.

If we want to solve this we should guarantee backward compatibility

Right, that's why I wrote to keep the issue until the first major release of EDC. As discussed already, the linked documentation requests x-www-form-urlencoded body.