Re: [Wish] Authentication for resource url

[Sergio Garcia Murillo <[e-mail]>]

I disagree with the approach.

IMHO, using username/password authentication in http rest apis is insecure
as it forces the user to store it's password into several "low security"
applications and most service providers have deprecated it in favor of a
token based authentication.

My proposal would be that it is a MUST for clients to support
authentication via the bearer token and it would be optional for the server
to implement it or not. In case the user does not provision the token on
the whip client, an unauthenticated request would be sent to the server.

Best regards
Sergio

El lun, 13 sept 2021 a las 18:14, Juliusz Chroboczek (<[e-mail]>)
escribió:

> > I understand the motivation, but this doesn't get us to
> > interoperability. We need a baseline, mandatory-to-implement
> > authentication method for both client and server; otherwise, we'll end up
> > in a situation where your client implements mechanism A, my network
> > implements mechanism B, and your users can't use my network.
>
> Yes, and that is why I suggested HTTP Basic instead of bearer token.
>
> Most servers today implement authentication using a username/password
> pair.  While this is certainly not the most secure solution, it is well
> understood by users, and is therefore likely to remain the main mode of
> authentication for the foreseeable future.
>
> With HTTP Basic, it is perfectly clear how to map a username/password pair
> to the protocol.  With bearer token, the client and the server need to
> both agree on how to map the username/password pair to a token, and
> I expect different implementations to use different mappings, with all the
> fun that this entails.
>
> So I suggest that for clients:
>
>   - support for unauthenticated WISH over HTTPS is MUST;
>   - support for HTTP Basic over HTTPS is MUST;
>   - other authentication methods is MAY.
>
> If that is not what Sergio has in mind, then the draft needs to mandate an
> unambiguous and deterministic way of mapping a username/password pair to
> an authentication method.
>
> -- Juliusz
>