Re: [Wish] Authentication for resource url

[Matt Ward <[e-mail]>]

AFAIK today, there's no "Auth token" input for any of the other services?
Have you found an ffmpeg output that supports bearer
authentication? Usually, more UI/params/config => more state => more
complex clients => longer time to integrate.

I want every single box that supports RTMP today to add WHIP tomorrow with
minimal friction!  :)

On Mon, Sep 13, 2021 at 10:55 AM Sergio Garcia Murillo <
[e-mail]> wrote:

> Not sure how an RTMP implementation may affect how OBS or ffmpeg
> implements WHIP, should be as simple as this:
>
> [image: image.png]
>
> El lun, 13 sept 2021 a las 19:29, Matt Ward (<[e-mail]>) escribió:
>
>> In the current abstract for WHIP, the spec comes out stating "Currently
>> there is no standard protocol (like SIP or RTSP) designed for ingesting
>> media in a streaming service, and content providers still rely heavily on
>> protocols like RTMP for it."
>>
>> Why do content providers rely on RTMP and possibly more interestingly,
>> why do publishers/broadcasters/end-users love RTMP?
>>
>> It is dead simple.
>>
>> If our goal is to replace RTMP, I think we need to allow clients to be as
>> dead simple as RTMP is today. In order to do this, we must allow clients to
>> ship with support for only path based authentication as in RTMP. This will
>> require a minimal amount of UI/UX changes and speed time to support in many
>> broadcasting software/appliances.
>>
>> As for MAY support beyond that, I'd look at how custom RTMP is configured
>> in OBS. To that end, it only supports authentication via basic auth. I
>> imagine adding support for bearer authentication that's only supported for
>> WHIP in OBS adds complexity to that client. I imagine this additional
>> burden would not be uncommon across the space of existing broadcasting
>> software/appliances. As for one more example, I have seen approximately 0
>> ffmpeg example commands outputting with bearer authentication.
>>
>> [image: Screenshot from 2021-09-13 10-16-54.png]
>>
>>
>> On Mon, Sep 13, 2021 at 9:30 AM Sergio Garcia Murillo <
>> [e-mail]> wrote:
>>
>>> 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
>>>>
>>>