Open-EO / openeo-api

The openEO API specification

http://api.openeo.org

Apache License 2.0

92 stars 11 forks source link

Improvements regarding signed URLs #380

Closed m-mohr closed 3 years ago

m-mohr commented 3 years ago

Solves issue #379

soxofaan commented 3 years ago

After pondering some more on this, some thoughts:

shouldn't we be more enforcing about the expiration time for security reasons (e.g. at least explicitly RECOMMEND it)? The current statement "Back-ends are responsible ..." is weaker than a recommendation I think.
Would it make sense to let the user choose whether they want public signed URLs that can expire or URLs protected with bearer token auth (that can not expire)? The expiry problem is mitigated by the renewal mechanism, but security minded users might want to avoid publicly available URLs that they can not invalidate themself.

I know, the tin foil hat factor of these points is quite high, and it's probably not urgent to tackle these the moment, but it might become a problem in the future.

m-mohr commented 3 years ago

shouldn't we be more enforcing about the expiration time for security reasons (e.g. at least explicitly RECOMMEND it)? The current statement "Back-ends are responsible ..." is weaker than a recommendation I think.

As also stated above, I'm not sure how high the security risk is actually, so I'm not sure this is actually required.

Would it make sense to let the user choose whether they want public signed URLs that can expire or URLs protected with bearer token auth (that can not expire)?

I assume that could make sense, but that would need to be tracked in a new issue for 2.0 (breaking for clients).

The expiry problem is mitigated by the renewal mechanism

The wording we add here doesn't necessarily mean that previous signed URLs get invalid, it just means expired links will be renewed. Revoking signed URLs is a different issue: #341 We may decide that re-requesting this endpoint also invalidates previously generated signed URLs, but currently that's not the intention yet.

soxofaan commented 3 years ago

I didn't know about #341 , that should indeed tackle most of the concerns raised here.

m-mohr commented 3 years ago

@soxofaan It seems this is important for you? I can certainly move the milestone up for #341 and make a proposal for API 1.1 in the next days.

soxofaan commented 3 years ago

Well, to give some background: the current implementation that @laxiwuka is working on for the VITO backend does not allow invalidation (there is no storage, just an added hash in the URL based on a secret to check that the URL hasn't been tampered with). The only tool to improve security is using shorter expiration times (changing the secret would invalidate all URLs for all users).

341 requires more work (because of persistent storage involved) than other alternatives (that do not require persistent storage or state) I am exploring here:

push the spec to make expiration times as short as possible
make it possible to opt-in for bearer-token based urls
allow user or client to set expiration time in some way

m-mohr commented 3 years ago

Thanks for the details, @soxofaan. It sounds like this is not your long-term solution though so I'll merge this and have opened PR #381 with a proposal to revoke signed URLs.

soxofaan commented 3 years ago

Yes, good to merge this already. Another follow up about toggling between signed urls and bearer token download urls: #382