ivoa-oauth: an SSO-next based approach to allowing non-browser-based VO clients to use OAuth 2.x/OIDC

[James Tocknell]

Hi Russ

By "dynamic client registration" I'm referring to RFC 7591 and OpenID Connect
Dynamic Client Registration 1.0 (the former based on the latter), both of which
allow for clients (not users!) to be registered without a browser (it is a
simple POST endpoint). This I would argue is the key part of "ivoa-oauth" (and
the reason I added in the additional challenge and discovery endpoint),
because without it (and requiring users to copy a client_id string into their
client), the value of autodiscovery is undercut. If we're not going to do
dynamic client registration, then the next two options I think are viable are:

    1. Mandate a client_id that every VO client can use. This is what the ESO
    Archive does currently, but now from the service side you have no insights
    into what different clients are doing (and basically pushes the service
    provider to only use the Device Authorization Grant, even for clients that
    could use the Authorization Code Grant). This also assumes that
    authentication providers will allow for a specific string as the client_id.

    2. Don't use OAuth 2/OIDC at all, and have a web service which gives tokens
    which users copy-paste into the relevant place. I've previously implemented
    this for a team-specific app we run, and Data Central has looked into making
    this into a service to run across all our services, but practically you lose
    revocation/expiration (because otherwise you get lots of support requests
    and grumpy astronomers complaining about you), and you then need to think
    about what else you need and end up with half of OAuth 2 without
    revocation/expiration and probably worse security.

I would prefer option 1 over option 2, but I wouldn't be surprised if some
groups cannot do option 1, and so we're left with option 2.

Ideally we work out what's needed to make dynamic client registration acceptable
to all groups and stakeholders, but I would suggest that the following would be
non-negotiable:

    1. All non-malicious clients can access VO services (i.e. we don't pick
    winners, no-one needs to add their client to a central database).

    2. Users (by which I mean astronomers) are able to run clients wherever they
    think is appropriate. There can be no mandate on additional software (e.g. a
    browser) that can communicate with the client.

>From the Data Central side, I think the only additional constraint we'd want to
add would be that the registration endpoint would be separate to the discovery
endpoint, as we would likely proxy access (via a service which would try to
filter out malicious clients) to the built-in Apereo CAS registration endpoint.

As for what we call the challenge, and exactly how we handle discovery, I'm not
that fussed.

Regards
James

________________________________________
From: Russ Allbery <eagle at eyrie.org>
Sent: Friday, 11 October 2024 5:26 AM
To: James Tocknell via grid
Cc: James Tocknell
Subject: Re: ivoa-oauth: an SSO-next based approach to allowing non-browser-based VO clients to use OAuth 2.x/OIDC

James Tocknell via grid <grid at ivoa.net> writes:

> To contextualise this a bit more, I'm doing a fair bit of hedging and
> leaving a fair bit open for discussion/flexibility because I feel the
> main sticking point for whether this will work is less on the technical
> side, and more on the can existing providers implement this in a
> political and policy sense. This is because there is some sense of
> ownership of authentication/authorization by organisations (for good
> reasons!), and sometimes this affects how they view how their systems
> should be used.

Yes, that makes sense to me. It's frequently the case that authentication
and authorization systems are run by an entirely different team, often
with an entirely different reporting structure, and they are very
reluctant to change how their system works to accomodate individual
scientific applications.

>> Like Mark, I am somewhat surprised that the protocol doesn't just use
>> Bearer for all subsequent Authorization headers from the client. This
>> is what all existing client libraries are going to expect to be able to
>> do, and I'm not sure I see the benefits of using a non-standard (from
>> the general client OAuth 2 library perspective) authorization type.

> This is one of the bits where I'm trying to give a bit of leeway to
> service providers. If we require `Bearer` be used, then service
> providers would have to spend the time checking that their systems
> aren't giving privileges to arbitrary clients that they should not have
> (because the whole idea of this is *anybody* can create a client, not
> that clients need to be approved and verified), as may be the case with
> existing system using OAuth 2/OIDC.

Well, the client is approved and verified by the user who is registering
it, but I think I see your point. Your concern is that there may be a
site that is willing to enable a device registration flow *only if* it can
guarantee that this device registration flow is only used by IVOA protocol
clients for a specific set of services and the resulting tokens cannot be
used anywhere else in their infrastructure?

The thing is, though, I don't think this Authorization header change
really helps here. Generally, the OpenID Connect implementation is going
to be something off the shelf and will probably be used for more than just
one service at most sites. If it issues a token via the device
authorization flow, then that token is going to be usable as a security
token for that user and that device in most of the off-the-shelf OpenID
Connect systems that I'm familiar with. There's no "token can only be
used with a non-standard Authorization type" setting, I think. You need
to do something with the token audience or otherwise limit the scope where
the token can be used.

So I'm not sure how this helps. It feels like it just adds client and
server pain but it doesn't address the potential site concern about
enabling device authorization flow, since one could just put that token
into bearer anyway and have it work.

I'm probably missing something. Maybe a more specific example?

> By splitting the possible clients into "VO clients, anyone can create
> one" and "officially approved clients", we can use existing Single Sign
> On providers, and resource servers can decide whether a VO client can do
> a specific action e.g. I would not expect a VO client to be able to
> delete my account, but it seems reasonable that a first-party client
> (like the SPA users create/modify/delete an account with) could do that.

I certainly understand this security model and why some sites might want
it. I'm just missing the connection with the Authorization header syntax.

> There'd also the weirdness of the challenge being `ivoa-oauth2` and the
> response being `bearer`, but that's a minor thing.

Honestly, I'd rather fix that as well: make the challenge be bearer but
add other IVOA-specific attributes to tell the client how to go get that
bearer token following our protocol.

> I think we're in agreement here, I'm only referring to the need to have
> the browser and the client communicate directly (which is effectively
> what RFC 8252 pushes for), not that credentials have to be entered into
> the client. I would expect user registration happens in a browser
> (because of forms that need filling).

Ah, okay, so in essence you're saying the same thing that I am: there has
to be some sort of registration flow where the user can go off separately
with a browser, complete it, and then cut and paste the resulting
credentials into the client, since the client may not be able to spawn the
browser directly.

> I'm guessing (not having used the Rubin Science Platform, but having
> interacted with Rubin systems as part of In-Kind and IDAC work) that
> Rubin is/will be using off-the-shelf OIDC systems (Dex?).

For the OpenID provider, Rubin uses CILogon (https://cilogon.org/faq<https://cilogon.org/faq>) for
the general user population and local installations of Keycloak for
various internal systems. For the relying party that sits in front of all
of our services, we have a very specific set of requirements and a set of
infrastructure goals that led us to write our own, called Gafaelfawr.
Further information is available at:

https://gafaelfawr.lsst.io/<https://gafaelfawr.lsst.io>
https://dmtn-234.lsst.io/<https://dmtn-234.lsst.io>
https://dmtn-224.lsst.io/<https://dmtn-224.lsst.io>

> Data Central is similar in that we use Apereo CAS for OAuth 2/OIDC (and
> we require 2FA for certain (non-VO) services, and it can do WebAuthN, so
> I'm aware that an actual full-featured browser may be required), and so
> I wrote the document as something that I could implement against our
> systems.

Excellent, yes. This sounds like a good reference use case.

> Dynamic client registration without a browser does to me seem like a
> must, as otherwise people are going to start hardcoding credentials into
> libraries and reusing them all over the place, and making it easy to
> register new clients (and thereby being able to track and monitor them)
> feels like it would reduce the occurrence of that.

I assume that by "dynamic client registration without a browser" you mean
that the client tells the user the information that they need to go do the
registration and the user then goes off and does that in a browser, gets
the resulting credentials, and pastes them back into the client somewhere?
I'm just double-checking because, to me, this is not "without a browser";
the user still very much has to use a browser. It's just without the
client spawning the browser directly.

> Also, given we're requiring dynamic client registration, and it may be
> concerning for some groups to switch this on their provider, having
> something proxying requests to their IDP's dynamic client endpoint would
> give them more control over the system (e.g. I'm thinking if they were
> using JWTs for the tokens, they may choose a specific `aud` value for
> first party vs VO clients, and the IDP may not provide a way to force
> that on the dynamic client endpoint).

So, again, though, I'm not entirely sure how this helps, because dynamic
client registration still has to be turned on for the IVOA thing to kick
it off, so presumably it's still accessible directly? The user's browser
is going to need to be able to talk directly to the authentication system
at some level in order to authenticate what user to associate with the
client, and the OpenID Connect authentication provider is, at some point,
going to have to issue the token.

--
Russ Allbery (eagle at eyrie.org) <https://www.eyrie.org/~eagle/<https://www.eyrie.org/~eagle>>