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

[James Tocknell]

Hi Mark and Russ

Thanks for the feedback!

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.

Two examples I can think of were the complexity around was trying to get Data
Central and CASDA to be able to authenticate for each other, which ran into
issues around CASDA using CSIRO infrastructure for authentication and hence
CSIRO be very reluctant to work with a third party that they didn't have much
control over; and MWA using eduGAIN to authenticate users but running into
issues where specific university IDPs (even though they were registered with
eduGAIN) had allowlists for which services the IDPs could be used for.

If amongst all the VO providers who use this challenge system we find
specific bits are not required because we're all got reasonable stakeholders,
then we drop those and be much more focused.

Going through the feedback: 

> - The scheme name "ivoa-oauth2" in the WWW-Authentication challenge
> should be fine if you think it's a better choice than "ivoa-oauth",
> I don't forsee any restriction to alphabetic names here.

I think it should be fine also, but I also wouldn't be shocked if some library
has hardcoded the assumption that numbers wouldn't be used, so I think we're
going to need to flexible initially just in case while we actually find out what
libraries assume.

> - There may be devils in the detail of the "allowed_domains" response;
> will it just be hostnames or something at a coarser/finer level?
> Hopefully there's some existing standards text that could be co-opted
> here (maybe the Origin concept from RFC6454).

I was thinking at least hostnames, but we should be as specific as possible
without being burdensome. I'm not sure if we want to list every endpoint, but it
would appear from a quick reading of RFC 6454 that RFC 6454 is a good starting
point.

> - It's not clear to me at what stage the user supplies a username
> and password - I assume that happens somewhere?
> Is it when the client registers with the registration endpoint
> as per Section 2 of RFC6749? If so (and, probably, in any case)
> it will be necessary to specify exactly how this authentication
> is done, e.g. mandating Basic Auth.

This is done as part of the OAuth 2 grant/flow process,
and each grant is different (in many ways not that different from the
standard_id from SSO).

For the Device Authorization Grant/Flow, the user
would enter the credentials (which may include username/password, 2FA, hardware
token or other parts) in a browser, but the client and browser never talk
directly to each other, which is what is required in all the other "modern"
(i.e. not being removed in OAuth 2.1) grants.

> - I'm surprised that having got the token you present it in the
> Authorization header (in the general case) using the scheme name
> "ivoa-auth" rather than just "bearer"; I'd have thought that
> having got the thing you would just treat it like a standard
> bearer token. But there may be some good reason for this.

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

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

> I don't think it's a realistic requirement in the general case for the
> client to not have to call out to a browser for at least the initial
> registration of the client. (Renewal, of course, is another matter.) To
> use Rubin for one example, I think it is relatively unlikely that we will
> ever allow dynamic user authentication of a client (in other words,
> authentication without separately obtaining a token first via a browser)
> without using a web browser.
>
> The requirements for the user authentication step are very complex and, in
> the typical case, involve an entire custom web UI as the primary intended
> interaction mechanism. They may involve discovery services, user
> selection of their home institution, arbitrary multi-factor authentication
> mechanisms, and at some sites even browser or local system authentication
> to the login service via client-side TLS certificates. I don't think it's
> likely that a client would be able to support the general case of user
> authentication without essentially implementing a web browser, with all
> that that entails.
>
> The only way that we've been able to think of to support clients with no
> access to a browser is to have the user run through some authentication
> flow (ideally the device authentication flow) elsewhere, where they have
> access to a browser, and then copy the resulting credentials into the
> client. (In other words, still a call out to a browser, just done via the
> manual intervention of the user.) This has other unfortunate consequences
> and, as with any solution that involves copying credentials, comes with
> some unavoidable security risks, but I'm not sure there is a good
> alternative.

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

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

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.

> The GET endpoint of this discovery service seems to be returning content
> very similar to the standardized /.well-known/openid-configuration
> endpoint. I know you address this directly later in the proposal, but I
> would really like to see the IVOA avoid defining its own discovery
> protocol, and instead specify a set of constraints on OpenID Connect and
> use OpenID Connect discovery, which is very mature and has a lot of
> existing implementations for both the client and the server. I know it's
> a huge, sprawling standard, but a lot of the complexity can be "turned
> off" by narrowing, for IVOA purposes, the list of options that servers are
> required to support and clients are required to implement for
> interoperability.
>
> My recollection is that OAuth 2 does not have a similar concept, so
> perhaps we need to define something for services that want to use only
> OAuth 2 and not OpenID Connect, although personally I would strongly
> recommend anyone newly implementing a protocol like this today use OpenID
> Connect and not "raw" OAuth 2. It standardizes and simplifies so much of
> the implementation space for you, without many drawbacks that I've seen.

The OAuth 2 equivalent is RFC 8414, and aims to be compatible with it (RFC 8414
calls this out), I only found it via
https://datatracker.ietf.org/wg/oauth/documents/ so I'm not surprised it's not
well known :)

This is another bit where I'm starting flexible and want to hear what the needs
of other groups are. I initially thought about only listing the
`oidc_discovery_url`, `allowed_domains` and the `registration_url`, but if some
third party provider only gives the RFC 8414 or has no discovery endpoint then
things are more complex and we continue down the path of bespoke wrappers around
specific providers (e.g. I wrote one for logging into the ESO archive, and I'd
like to be able to deprecate it).

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

Regards
James