<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I can think of several simple ways: <br></div><div class="gmail_default" style="font-size:small">1. user authenticates in browser and then downloads a (bearer) token the various tools can use</div><div class="gmail_default" style="font-size:small">2. user authenticates in browser and then <span class="gmail-ng">downloads</span> proxy cert the various tools can use</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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 lot of people have been convinced that typing username and password into a browser window is inherently more secure than into a topcat window and you can trust one (*cough*google chrome*cough*) but not the other and you don't get to choose.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Well, you can see that this topic annoys a lot :-)<br></div><div class="gmail_default" style="font-size:small"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 5 May 2022 at 01:50, Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On the topic of OpenID authentication for non-browser clients that I<br>
mentioned in my earlier email; although CADC currently issue a challenge<br>
<br>
www-authenticate: ivoa_bearer standard_id="ivo://<a href="http://ivoa.net/sso#OpenID" rel="noreferrer" target="_blank">ivoa.net/sso#OpenID</a>", access_url="<a href="https://ws-cadc.canfar.net/ac" rel="noreferrer" target="_blank">https://ws-cadc.canfar.net/ac</a>"<br>
<br>
I understand from Brian that they don't really expect OpenID Connect <br>
to be used by non-browser clients, and hence that it doesn't need to <br>
be declared as a challenge in this way (and may therefore be withdrawn).<br>
<br>
However, I understand from Alberto that ESO will require use of OpenID<br>
for all clients wishing to authenticate, on the grounds that SSO via <br>
tls-with-password or BasicAA, which involve presentation of username <br>
and password to untrusted desktop clients, are insufficiently secure<br>
to meet their policies.<br>
<br>
Implementation of OpenID Connect-based authentication by non-browser <br>
clients such as topcat is not impossible, but it probably requires <br>
browser interaction as described by RFC8252 and therefore represents <br>
a significant client implementation burden as well as having usability <br>
impacts.<br>
<br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a> <a href="http://www.star.bristol.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bristol.ac.uk/~mbt/</a><br>
</blockquote></div>