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

[Paul Harrison]

> On 11 Oct 2024, at 09:41, Mark Taylor via grid <grid at ivoa.net> wrote:
> 
> On Thu, 10 Oct 2024, Russ Allbery via grid wrote:
> 
>>> There'd also the weirdness of the challenge being `ivoa-oauth2` and the
>>> response being `bearer`, but that's a minor thing.
>> 
>> Honestly, I'd rather fix that as well: make the challenge be bearer but
>> add other IVOA-specific attributes to tell the client how to go get that
>> bearer token following our protocol.
> 
> We could do that, but I don't know why it would be desirable,
> and I don't see a problem with the challenge auth-scheme and the
> first token in the Authorization header having different values.
> The other SSO_next schemes don't follow that pattern; ivoa_cookie
> and ivoa_x509 don't use the Authorization header at all.
> 
> If we use "bearer" as www-authenticate challenge auth scheme,
> then we're sitting on top of RFC6750 and might possibly run into
> compatibility issues with that standard or interfere with other
> Bearer-related auth-param namespaces.  If we use our own scheme
> "ivoa-oauth2" we can do what we want.

I have some reservations about the whole approach of having our own auth schemes

* Security is important and the SSO protocols are fairly complex, so it is probably good practice to use established libraries/servers in the implementation - the libraries might not have easy hooks to change the headers from the “standard” ones.
* It might be the case that various firewall/proxy settings might reject non-standard header values.
* Although it seems like an obvious thing to put in the URL of where to access a Bearer token in the www-authenticate header it does not seem to be done particularly widely - perhaps again this is done for security reasons so that it is not easy for a bot to attempt a denial of service attack on the authentication service. - We do have a solution for this as the service will have been discovered in the registry, so the information could be there.

Paul..
-------------- 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/20241011/4d3c44f6/attachment.p7s>