OpenID and SSO

[Mark Taylor]

On Thu, 5 May 2022, Patrick Dowler wrote:

> It is true that on the one hand we tell everyone "if a web site asks for
> your user name and password for some other site, it's a phishing attack"
> and I suppose a lot of this is based on now thinking that applications are
> by definition no longer to be trusted. The part I don't like about it is
> that it's the user that should make that (hopefully informed) call about
> trusting topcat (or not :-)) but that's not how things work anymore. The
> world of mobile "apps" has blurred the line between web sites and your own
> applications so now using an application that can do authentication is a
> "phishing attack". #sigh

Of course I'm sympathetic to Pat's comments.  For desktop applications
like topcat or python, the user installing them has already given them
the ability to do things like read/write/delete private files and
make unrestricted network connections, which is different than
the relationship a user has with a web application.
But there may be cases where institutional policies don't recognise
that distinction.

> Probably a question for Alberto: How would/will ESO enable their users to
> use applications like topcat, pyvo, astropy, etc to access their services
> with auth?
> 
> I can think of several simple ways:
> 1. user authenticates in browser and then downloads a (bearer) token the
> various tools can use
> 2. user authenticates in browser and then downloads proxy cert the various
> tools can use
> 
> These can work; maybe ESO users will be OK with that. We (CADC/CANFAR) have
> a link for #2 on our site when then user is logged in and we could have one
> for #1 except users wouldn't know what to do with it (chicken-vs-egg
> problem w.r.t the applications)... and really they should generate and
> manage separate tokens for different things... like github, google, and
> everyone else does now. So industry-wise it looks like #1 is the de facto
> solution for this, but I find it a pain as a user.
> 
> Anyway, the solution for ESO and ESO users is probably #1, so topcat
> probably needs to be able to read tokens (like certs) from a file or
> command line or cut&paste into a text box. It's really ugh but somehow a

I don't think it's quite as bad as that.  I haven't done the
implementation so far, but my understanding from RFC8252 and from
using other applications that do this is that #1 can be automated
to some extent, so the user experience is something like:

   - desktop client tells user to visit a given website in a browser
     and enter a short supplied character sequence
 
   - user opens that website in a browser, types/pastes in character
     sequence, and logs in (unless they are already authenticated
     in the browser, in which case logging in again is not necessary)

   - browser and desktop client communicate under the hood and
     permission is granted to client without further user intervention

This is somewhat painful, but not absurdly so.

I certainly support the choice of organisations like CADC willing
to provide SSO options that allow a more traditional user interaction
(just type in username and password to the application).

But if there are organisations who don't find that acceptable,
SSO should support describing their supported methods
(as I've argued elsewhere, I think that
"www-authenticate: ivoa_openid access_url=..." would be the best
way to do that).
Whether individual clients then provide client-side support for
such methods, given the significant complication involved,
is another question.

Mark

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/