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

[Russ Allbery]

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) 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://dmtn-234.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/>