text/html option
2022-06-27T10:32:59.156Z [BaseHttpServerFactory] info: Received GET request for /timbl/Automation/mother/state.n3
2022-06-27T10:33:00.500Z [DPoPWebIdExtractor] warn: Error verifying WebID via DPoP-bound access token: "iat" claim timestamp check failed (too far in the past)
2022-06-27T10:33:00.511Z [WebAclReader] info: Reading ACL statements from https://timbl.com/timbl/Automation/mother/.acl
2022-06-27T10:33:00.513Z [PermissionBasedAuthorizer] warn: Unauthenticated agent has no read permissions
3 replies
iat claim is part of the openid spec so not something that can just be removed, although I'm not sure how strict the 5s range is, @matthieubosquet would know
2022-06-27T18:25:28.001Z [WrappedExpiringReadWriteLocker] error: Lock expired after 3000ms on https://timbl.com/[...]
2022-06-27T18:25:28.006Z [StreamUtil] warn: Piped stream errored with Lock expired after 3000ms on https://timbl.com/[...]
2022-06-27T18:25:28.006Z [BasicResponseWriter] error: Writing to HttpResponse failed with message Lock expired after 3000ms on https://timbl.com/[...]
2022-06-27T18:25:29.008Z [GuardedStream] error: No error listener was attached but error was thrown: aborted
Validating the iat claim with a five seconds margin comes off this recommendation:
If an adversary is able to get hold of a DPoP proof JWT, the
adversary could replay that token at the same endpoint (the HTTP
endpoint and method are enforced via the respective claims in the
JWTs). To prevent this, servers MUST only accept DPoP proofs for a
limited time window after their iat time, preferably only for a
relatively brief period (on the order of a few seconds).
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-04#section-10.1
It has been relaxed in the latest DPoP draft:
(preferably only for a relatively brief period on the order of seconds or minutes)
— https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-09#section-11.1
But I think it's fine to relax the DPoP proof to 2 minutes max age.
PR: https://github.com/CommunitySolidServer/access-token-verifier/pull/173/
As far as I understand, the requirement for DPoP proofs became evident mostly because of mobile devices (secure access token usage is more challenging there).
But Solid OIDC doesn't require the DPoP binding of access tokens.
For example, from the access-token-verifier's perspective, Access Tokens can be 24 hours old by default.
It seems that DPoP binding is becoming more widely accepted as good security practice beyond mobile devices, but I don't think that more lenient methods will disappear overnight.
In other words, DPoP is just one of many attempts at improving the security of Bearer tokens, but a client that lacks confidence in its clock (which sounds like a very edge case after increasing the lenience to the order of several minutes) could very much just use a simple Bearer Access Token (not DPoP bound).
I don't think that it is advisable to not use DPoP though. Hopefully a lenience of 2 minutes is enough and potentially one might increase it to slightly more if empirical evidence shows it is a strong need.
For the sake of completeness in the matter:
- The iat claim in DPoP tokens is used to prevent replay attacks.
- Preventing replay attacks is also ensured via the jti claim (a unique identifier).
Therefore, the balance to strike is between the size of the jti index and the age of tokens. In other words, if I keep a list of all jtis of tokens used in the last 2 minutes, I'm fine to say that DPoP tokens can be at most 2 minutes old, but that has a cost and becomes also more challenging when a system is distributed and so on (in other words, the default JTI cache and settings of the access-token-verifier have been designed to accomodate most use cases at a low cost in terms of infrastructure and setup).
But Solid OIDC doesn't require the DPoP binding of access tokens.
Current version of Solid-OIDC relies on binding ID token not Access Token, the later is issued by AS associated with RS and can't be used elsewhere
In Solid making ID Token sender constrained (by binding it to client's public key) is very important. Without it, the client could use that ID Token with AS associated with a malicious RS. When the token is not sender constrained that malicious AS+RS could start using that token and authenticating as a user with other RSs.
By making ID Token sender constrained, they can't do it since presenting token is not enough, the party acting as the client needs to prove that the token was issued for them, Solid-OIDC chooses DPoP as the proof of possession mechanism.
2022-07-01T09:47:25.319Z [BaseHttpServerFactory] info: Received GET request for /timbl/[…]ttl
2022-07-01T09:47:26.592Z [DPoPWebIdExtractor] warn: Error verifying WebID via DPoP-bound access token: "iat" claim timestamp check failed (too far in the past)
2022-07-01T09:47:26.606Z [PermissionBasedAuthorizer] warn: Unauthenticated agent has no read permissions
