Open carlonnheim opened 2 weeks ago
Hi @carlonnheim ,
Thanks for bringing this to our attention and also sharing your workaround. You're right, the proxy-auth token should be refreshed if it is expired before the cached destination is returned. I'll create a ticket in our backlog.
I cannot promise a timeline as we're currently low on capacity, but we will try to address it soon.
Describe the bug Destinations which use Authorization and Proxy-Authorization only consider the expiry time of the Authorization token when determining cache expiry.
To Reproduce Use a destination which has for example
OAuth2JWTBearer
with a service going through the SAP Cloud Connector via the connectivity service. Configure it withuseCache = true
.Make a request with one authenticated user. The framework obtains a Proxy-Authentication token to use with the connectivity service and the application token to use with the service being connected too. Both of these have an expiry time but only the application token is considered when determining the cache expiry. If the application token has a shorter expiry than the proxy token, the cached destination will start failing once the proxy token expires. Once the application token expires, the cache will be discarded and the next request will work again.
Make another request with a different user. The framework reuses the Proxy-Authentication token obtained during the first call, which can now have an arbitrary time-to-live left. A new application token for the other user is fetched. These are stored in the cache together and expires based on the expiry date of the application token. Once the proxy-auth expires, the destination fails until the application token eventually expires and the cache entry gets discarded.
Expected behavior The cached destination must expire based on the shortest lived token (application or connectivity proxy). Alternatively, the proxy-auth needs to be refreshed on cached destinations when it expires.
Screenshots We have worked around the issue with the following patch, which also further clarifies the issue. This includes excessive logging and is also not properly protecting for authorization tokens which are not jwt's (
decodeJwt
throws in that case), but I assume the proper solution to the problem might be different altogether anyway - this is just to clarify the issue.Used Versions:
Code Examples See patch above
Log file With the patch active (including its excessive logging), output looks like this (in this example both the proxy-auth and the application token have a 12h lifetime and the user connections are half a minute apart. The cached destination for User2 would have kept being used and fail the proxy-authentication after it has expired without the patch.
Impact / Priority Can't use cached destinations including a user JWT and on-premise connectivity in combination.
Affected development phase: Production but can work around
Impact: Impaired but can work around
Timeline: N/A
Additional context N/A