OpenID challenge

[Paul Harrison]

> 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 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, but because it is so ill-defined it is an “error condition” that has occurred when a token expires or is invalid. In the case of expiry, depending on the style of token, it might be possible to refresh the token without user intervention, but in that case I think that the expectation is that the app/browser has remembered the token generation URL or that it is well known in some way.

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.

Cheers,
	Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20220510/feb6556a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20220510/feb6556a/attachment.p7s>