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

[Russ Allbery]

Patrick Dowler via grid <grid at ivoa.net> writes:

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

Yeah, if the client is aware of and enforces this restriction, it will at
least make it harder to get the client to send the token off to an
attacker who can reuse it.

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

Indeed, cookies have all the necessary pieces but using them correctly is
a lot of careful work.  A lot of people just use domain-scoped cookies,
which both don't necessarily solve this problem and also introduce other
security concerns.

This phishing problem is inherent in bearer tokens, sadly.  Scoping the
domains helps (I wonder why that's not been standardized and I wonder if
there's some informative discussion behind that explaining when this
fails), but fundamentally the user's always going to be able to give their
bearer token to an attacker if they decide they want to do that.  To
really prevent this, one needs something like channel bindings that make
the bearer token useless outside of a specific connection, which aren't
really available here, or one needs a completely different authentication
protocol that's based on something like public key authentication rather
than sending reusable secrets over the wire.

As an aside, I think this protocol as proposed is also vulnerable to a
different type of phishing where the attacker phishes the initial
credentials by getting the user to do a device authorization code flow
against an attacker-controlled dynamic client.  In that case,
allowed_domains doesn't really help.  The problem instead is that there's
no good way for the authentication infrastructure to know if the dynamic
client is legitimate.

Trying limit that phishing was one of my reasons for making clients
one-use-only and *only* usable for device authorization flow, not any
other flow.  That at least prevents putting up a simple web site that does
OIDC and gets an access token that way, and should make it a bit harder
for the attacker.

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