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

[Patrick Dowler]

This has been interesting, but I'll chime in here on the custom/ivoa auth
schemes. The idea of those is that they are used in www-authenticate header
challenges to convey some info about how a client can acquire the
credentials but they are never used with authorization header to
authenticate. When actually authenticating, clients use standard mechanisms
(cookie: <blah>, authorization: bearer <blah>, etc)

The reason for inventing ivoa challenges is that existing challenges (eg
bearer from that RFC mark mentioned) have their own set of additional
properties they can convey when used in the www-authenticate (eg errors for
expires token) and it did not look like adding more of our own was valid.

As for actual naming, we had sort of settled on "ivoa_bearer" meaning "how
to get a token", "ivoa_x509" for "how to get a certificate", and
"ivoa_cookie" for "how to get a login cookie".

Anyway, kudos to James for taking another stab at this, and I think the
'allowed_domains' bit is the missing bit that tries to prevent enabling
phishing attacks (sending tokens to a rogue service in a different domain).
That's the bit that we always found missing from the sea of standards in
this area. Well, cookies have the implicit host/domain name and realm
stuff, but that ends up making issuing cookies for multiple domains (
cadc-ccda.hia-iha.nrc-cnrc.gc.ca and canfar.net) a pain.

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Fri, 11 Oct 2024 at 04:18, Paul Harrison via grid <grid at ivoa.net> wrote:

>
>
> > On 11 Oct 2024, at 09:41, Mark Taylor via grid <grid at ivoa.net> wrote:
> >
> > On Thu, 10 Oct 2024, Russ Allbery via grid wrote:
> >
> >>> 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.
> >
> > We could do that, but I don't know why it would be desirable,
> > and I don't see a problem with the challenge auth-scheme and the
> > first token in the Authorization header having different values.
> > The other SSO_next schemes don't follow that pattern; ivoa_cookie
> > and ivoa_x509 don't use the Authorization header at all.
> >
> > If we use "bearer" as www-authenticate challenge auth scheme,
> > then we're sitting on top of RFC6750 and might possibly run into
> > compatibility issues with that standard or interfere with other
> > Bearer-related auth-param namespaces.  If we use our own scheme
> > "ivoa-oauth2" we can do what we want.
>
> I have some reservations about the whole approach of having our own auth
> schemes
>
> * Security is important and the SSO protocols are fairly complex, so it is
> probably good practice to use established libraries/servers in the
> implementation - the libraries might not have easy hooks to change the
> headers from the “standard” ones.
> * It might be the case that various firewall/proxy settings might reject
> non-standard header values.
> * Although it seems like an obvious thing to put in the URL of where to
> access a Bearer token in the www-authenticate header it does not seem to be
> done particularly widely - perhaps again this is done for security reasons
> so that it is not easy for a bot to attempt a denial of service attack on
> the authentication service. - We do have a solution for this as the service
> will have been discovered in the registry, so the information could be
> there.
>
> Paul..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20241011/041c35ef/attachment.htm>