Re: [Wish] Authentication for resource url

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

I think in terms of UI it is very similar to what people are used to, for
example this OBS UI to connect to facebook would be exactly the same than
the one required for whip:

[image: image.png]

Where server is the whip endpoint url and the stream key the bearer token
sent on the authentication header. Even the "get stream key" button would
work the same way.

Best regards
Sergio

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

> It may be trivial for you to wrap your head around as the author of the
> spec and a strong engineer. However, I still feel quite strongly that
> converting a community of broadcasters (with a wide range of technical
> understanding) from RTMP => WHIP is easier if the protocol drops into
> existing UIs with near 0 changes required.
>
> Imagine working at Blackmagic or Teradek and seeing a requirement to add a
> bunch of UI in addition to a whole new underlying protocol. I suspect
> requiring even basic auth there will slow adoption.
>
> On Mon, Sep 13, 2021 at 11:09 AM Sergio Garcia Murillo <
> [e-mail]> wrote:
>
>> 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
>>>>>>>
>>>>>>