OpenID challenge

[Mark Taylor]

On Tue, 10 May 2022, Paul Harrison wrote:

> > On 2022-05 -09, at 14:27, Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:
> >
> > If VO service providers mostly or all decide that such arrangements
> > are unacceptable and that desktop clients must use browser-based
> > flows in order to authenticate, then yes some of these details
> > won't be much use. However, even in that case and supposing I'm
> > prepared to implement a browser-based flow, as a client author
> > I still don't know how to go from a bare "www-authenticate: bearer"
> > challenge to finding out where I can go to get a suitable bearer
> > token, so I still don't know how to offer the user a browser-based
> > authentication flow. Are there standardised rules about redirection
> > flows that could enable me to work that out?
>
> The point I was trying to make is that I think the intention is that
> you do not start at the “bare www-authenticate:bearer” challenge -
> after all browsers would have the same problem - the first step is that

It's not normally *browsers* that have to solve this, it's web
applications (i.e. groups of related web pages).  Web applications
are by their nature specific to particular services, and so can
naturally contain all the knowledge they need about where to go to
find tokens or whatever.  Desktop applications don't (at least in
the VO model) feature code installed by the service itself,
so have a different problem to solve.

> a redirect is issued to the URL of the token issuer. Then a call is made
> to the token issuer with one of the parameters being a callback URL that
> the token issuer then emits a redirect to with the token. I agree that it
> is fairly unclear amongst the standards what the browser is supposed to
> do if it gets a www-authenticate:bearer challenge. My guess is that the
> standards authors imagined that the body of the response might contain
> an error message with a suitable link that the user might click on,

Well, maybe... but as you say, it's not clear what steps an application
is supposed to take here, so there is a problem we need to solve if
we want desktop clients to be able to use authentication-protected
services without having per-service knowledge hard-wired into them,
which is something I would like to avoid.

> I also agree that having to interact between a native app and a web
> browser is not going to be elegant given the sandboxing.
> https://developers.google.com/identity/protocols/oauth2/native-app
> gives some examples and makes reference to
> https://datatracker.ietf.org/doc/html/rfc8252, and it seems that
> “custom URI schemes” are probably the favoured method at
> the moment, given the furore when Zoom tried to use "loopback
> interface redirection”. Although, I think that they just left
> a web server running continuously rather than follow the advice
> https://datatracker.ietf.org/doc/html/rfc8252#section-8.3.

Yes if browser-based interactions are going to be part of the solution
here, RFC8252 seems to be the relevant document.  I hadn't followed
that part of the zoom story, but I still think that the loopback
interface option would be the one I'd go for implementing, since
private URI schemes or claimed HTTPS domains look rather platform-specific,
hence java-hostile.

Mark

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