DapsValidator - JWT expired about ids-messaging-services HOT 6 CLOSED

clock skew = tolerance for the token expiration to deal with differences in the issuer time and consumer time and thus specifies the allowed time difference between the server and client clocks -> was set to 0 milliseconds here, so issuer and consumer need to have exactly the same time synchronized

sorry for closing and opening, used GitHub Shortcuts by mistake

from ids-messaging-services.

Hi Tim, I had a second look into the logs. It seems that the connector is complaining about its own token. Could it be that before sending a request to another connector it gets its own token from the DAPS, checks it and realizes that the token is too old? In this case there is a clock skew of 7 seconds between the connector and the DAPS.

from ids-messaging-services.

Hi, the +7 seconds then fit to the log message from above difference of 7343 milliseconds.

I am not aware that we do a validation, however I can find the following reference in the DAPS specification regarding sending the request token for a DAT to the DAPS at Request token that is handed in at DAPS side: "If the system time [of the connector] is not in synch with the DAPS, the request token will be rejected (e.g., nbf [not before] is in the future)."

Link: https://github.com/International-Data-Spaces-Association/IDS-ThinkTank/blob/10e7ef999177c9f76e44f16ae49c31640ba562c7/ids-communication-guide-working-draft/Interactions%20with%20central%20Components/CONNECTOR%20IDENTIY%20PROVIDER.md

from ids-messaging-services.

Hi, after checking the logs again I realized that the failing communication (as stated at the beginning) had another reason. It seems that the clock skew error is not a real error. I see that after the error message the AisecTokenManagerService is downloading a new token which works.
My explaination for the error is the following now. Since the job is running every hour I assume that the token has a validity of 1h (which seems quite long). When the job starts again it checks the old token it has cached and realizes that the token is too old. It throws an error message and handles the situation by downloading a new token.
But since the situation is already handled (because it is expected that the token can be expired), no error message should be thrown in this case.

from ids-messaging-services.

If it should be only about the pure log message, then we cannot easily prevent it, since it is not thrown by the Dataspace Connector itself or the Messaging-Services at all.

To read the claims of the cached DAT to get the expiration we use the Jwts.parser() (io.jsonwebtoken.Jwts), which unfortunately checks before us whether the tokenvalue is valid at all. For example, if it has expired, the parser throws an ExpiredJWTException on the one hand and logs a message that we cannot control on the other. We catch the exception and get a new token or in case of no exception we execute our own validation afterwards and then get a new one depending on the result.

The only way without this log would be to not use the parser at all at this point. For this we would have to read the claims directly when we receive the DAT from the DAPS and save them additionally to the complete JWT, such as the info of the expiration date, which should still be valid directly after receipt. By that we would be able to access the info directly when checking if the DAT has expired instead of having to re-read the claims and using the parser.

from ids-messaging-services.

(have implemented the solution to also cache the expiration date directly after fetching the DAT next to the DAT itself, instead of reading the claims via the parser every time a message is sent and thus running into the error-log)

from ids-messaging-services.