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

[Russ Allbery]

Thank you for this!  I am very interested in having a standardized way to
authenticate clients via a Device Authorization Flow, but concrete work on
that has unfortunately been pushed back due to other priorities.  But this
is definitely something that I want to implement for our services, so I am
happy to see work on standardizing how it should be done.

I have only had a relatively brief look at the document, so just a few
comments on things that stood out.

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

> 2.  Must work for non-browser clients

>     a.  Non-browser clients should not be required to call out a
>         browser, nor run a web server for redirects (this covers
>         situations where clients are running on a remote server or are
>         otherwise unable to contact a browser directly)

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.

> #### The discovery endpoint

> The discovery endpoint MUST return a JSON document with the following
> keys:

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.

> -   `allow_bearer`: A boolean representing whether `Bearer` may be used for
>     `access_tokens` against resource which are managed by this service. This
>     exists solely to simply code that uses off-the-shelf libraries to handle
>     OAuth2/OIDC (**COMMENTARY: we may want to drop this anyway, if services
>     would find this painful to support?**).

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.

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