Re: [Wish] Authentication for resource url

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

FWIW, I did implement the initial whip draft in OBS and doing the UX for
configuring the oauth token is trivial. The problem with ffmpeg is not
going to be the bearer token authentication neither.. ;)


El lun, 13 sept 2021 a las 19:56, Matt Ward (<[e-mail]>) escribió:

> 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
>>>>>
>>>>