[Ops] VO-wide API keys

[Markus Demleitner]

Hi James,

On Mon, Dec 09, 2024 at 07:21:51AM +0000, James Tocknell via ops wrote:
> This is similar-ish to OAuth 2.0 (though the keys are not
> long-lived, you need to use refresh tokens), and so the SSO-next
> discussion somewhat covers this (but these API keys are really
> about rate limits rather than auth?).

I'd say having to use a token refresh service may be marginally
acceptable, because it can hopefuly be hidden away from the users
most of the time, but it seems a lot of effort and fragility for
something that really should only give us a chance to tame largely
unintentionally misbehaving clients.

So, I'd like a constant string that people can use for years on end
if they don't mess it up (and hence set it up in their environment
once and then forget about it) much better.

> The issue I see is how long you want the token to last for: for
> early career researchers, they lose access to emails all the time
> switching between institutions, so you need either multiple emails,
> be able to switch email, or revoke them if the user is
> non-responsive, and it seems you're half way to building an
> authentication system?

Well, *if*, as I say, the main function of the whole thing is to
block clients going on a rampage on some data centre without that
having to block all of AWS, then there's no reason to have the token
expire at all.

Of course, as you say, the secondary function of us being able to
contact the script authors and explain to them what they should
rather be doing: That would bind the life time of our tokens to the
life times of e-mail addresses.  Unfortunately, these have a really
wide distribution (I personally have at least two adresses that still
work after 30 years...).  So, taking an average over the life times
of real mail addresses is not a particularly good metric.  And hence
I'd dodge the contact problem and say "well, if contact breaks,
that's not dramatic, just so long as we can still block rampaging
scripts".

        -- Markus