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

[Russ Allbery]

James Tocknell <james.tocknell at mq.edu.au> writes:

> No worries! It would be good to know what addition constraints Rubin
> would require on the Dynamic Client Registration side to be happy for
> clients to use it.

I was thinking about this a little bit last night, and my first cut at an
implementation plan would probably look something like this.  I'm not sure
any of this would require any changes to the specification, and I don't
*think* it requires the proxy or additional discovery service that you're
currently planning for, but I am probably missing something.

* Provide Dynamic Client Registration that creates a client that can only
  be used once, for a single authentication, and also times out after a
  short period of time (a day or so).  So dynamic registration could not
  be used to create a persistent client, just a temporary one that lives
  long enough to complete the Device Authorization Code flow once for a
  single user.  The initial client would be in a pending state with no
  association with a user.

* Support Device Authorization Code flow for those clients (and maybe with
  conventionally registered clients, but at least at first glance I
  probably wouldn't).  Once that flow is complete and credentials are
  issued (in our case, the ID token would be a JWT but the access token
  would not be, since we don't use JWT internally for a bunch of reasons),
  the dynamic client would be retroactively associated with the user who
  used it (for logging/auditing purposes) and disabled so that it can't be
  used again.

* The client then can continue to use the access token (and I really need
  to implement refresh token support and all of that as well) until it
  expires.  Once it expires, the client will need to dynamically
  re-register before it can authenticate the user again.

We would do all of this with OpenID Connect and ideally ignore the
non-OIDC OAuth 2 stuff.  We're pretty committed to OpenID Connect.

I haven't given this a ton of thought, so I'm probably missing some
security concerns, but at least at first glance this seems reasonably fine
to me.  There's some DoS risk from people spamming dynamic client
registrations, but they expire and we can throttle by IP address or
something.  This avoids dynamic registration of a persistent relying
party, which is something that we don't want to support.

This would probably require a custom implementation on the OpenID Connect
authentication provider, but we already have one of those, so that's not a
concern for us.

I have not looked at all the authentication flows.  There are probably
some specifics that need to be added there, but you've done way more
research on that than I have.  I'd need to do a bunch of reading before
starting an implementation.

> Also, if you do happen to know of any ecosystems that are using Dynamic
> Client Registration (because it seems its widely implemented in servers,
> but I've not seen anyone really talk about the ecosystem implications),
> that would be really helpful.

I have used OAuth 2 identity providers that support Dynamic Client
Registration and are willing to authenticate users to arbitrary sites, but
it's been a while.  I think most services and clients (such as mobile
clients and settop box apps) these days pre-register with the big identity
providers (Google, Facebook, Microsoft, GitHub for technical stuff) and
don't bother supporting arbitrary OpenID Connect providers.  I think
Dreamwidth may still provide a general-purpose OAuth 2 authentication
provider, but I'm not certain.

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