[Ops] VO-wide API keys

[James Tocknell]

Hi Markus

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?).

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?

Regards
James

________________________________________
From: ops <ops-bounces at ivoa.net> on behalf of Markus Demleitner via ops <ops at ivoa.net>
Sent: Monday, 2 December 2024 6:21 PM
To: ops at ivoa.net
Subject: Re: [Ops] VO-wide API keys

Dear Rick,

On Thu, Nov 21, 2024 at 12:44:08PM -0800, Rick Ebert via ops wrote:
> The services only need proof that the client _has a valid service
> key_
> the key should probably NOT be sent to the services ...
> as it is likely these api keys will be ... "long-lived" ...

+1 to long-lived. If people need to renew them more often than, say,
every six months, it'll be a chore (on the other hand, of course,
they'll have forgotten about how to do it after six months... hm).

On not sending API keys to the service... well, that increases
complexity by a large margin (you probably need challenge/response
then). Also: how would this be different from full Authn?

Me, I'd say there are two fairly different use cases:

(a) block rude users/perhaps be able to contact them

(b) control access to proprietary resources

While for (b), I have some sympathy to the notion that we want to
protect the credentials from stealing, I don't see that as a major
problem for (a); anyone can obtain API keys anyone, and cloaking as
someone else probably won't buy you much in our setting. Basically,
you could DoS another person until they get a new API key. Yawn.

So, my vote would be for not linking API keys to the more general
problem of federated Authn and look for the absolute minimum that can
possibly work.

> I further second the "adopt an existing deployed mechanism" criteria.

Sure, that would be nice. The only place I am using something like
this is for the ADS API; for them, the key just rides in an
Authorization: bearer: HTTP header, and I suspect the the string you
get has no internal structure (at least it doesn't seem to be
base64-encoded). Is anyone aware of systems closer to the digital
signature thing that I'd like[1] to have?

-- Markus



[1] No, not "like". Make that: "That I'd least dislike if we have to
annoy our users with API key management in the first place."

_______________________________________________
ops mailing list
ops at ivoa.net
http://mail.ivoa.net/mailman/listinfo/ops<http://mail.ivoa.net/mailman/listinfo/ops>