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

[Major, Brian]

Hi James, hi all,

On 2024-10-08, 7:08 PM, "grid on behalf of James Tocknell via grid" <grid-bounces at ivoa.net <mailto:grid-bounces at ivoa.net> on behalf of grid at ivoa.net <mailto:grid at ivoa.net>> wrote:

> I've written a draft idea for how to allow VO clients to use OAuth 2.x/OIDC to access VO resources.

To repeat what others have said:  thanks for taking this on!  It looks like a great start and must have been a lot of work to put those RFCs together cohesively.

> I'm happy to talk about this at the Interop (I'll be at both ADASS and the Interop this year), or discuss it over the breaks.

A talk would be great, James.  And maybe a splinter session?  I have a feeling there'll be a lot to go through.

In a kind of follow-up to the presentation on EduTeams given by Pierre LeSidaner and Albert Shih in Sydney, we at the CADC are looking at a similar hosted 'Authorization Server' to help us in the whole OIDC/AAI ecosystem (Authentication, Authorization, and Identity management--what we used to call A&A).  CILogon, currently used by LSST and many other research/science groups, is being recommended by the Canadian national infrastructure organization (DRAC).  We have plans to migrate our user-base and groups there, so we'll inherit the support for AAI protocols (like OAuth2 and OIDC) and not have to manage our users' secure and private information ourselves.  The plans are pretty high-level at this point and there are a few pieces we haven't figured out...

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

This is one of them and a critical authentication pattern we support.

x.509 client certificates, our current solution for this, are gradually fading away in favour of tokens.  We still haven't figured out:
- How to best obtain them.  The OIDC dynamic registration + device flow pattern is what we've been looking at as well.
- How to restrict the scope of their use, and, relatedly, how to use them for service-to-service calls in a way that the Credential Delegation Protocol allows us to do.

Another is how groups from different Identity providers/Proxies can work together and what that means for GMS.  Can a group be composed of members from different IdPs?

The primary reason we are looking at CILogon is because we require federated AAI solutions with numerous communities, including SKA/SRC and LSST/Rubin, in the near future.  CILogon and the experts in AAI at SRCNet recommend that federation support happen at the 'Authorization Server' level, not at the 'Resource Server' level.  (Using James's definitions.)

We are quite happy to pass support for this to the Authorization Servers.  In fact, and I think this would be agreed upon widely here, we really just want to do AAI in the simplest and most standard way possible, but continue to support the core concept of sharing via groups that is so important in many of our IVOA services.

Cheers,
Brian