Re: [Wish] Authentication for resource url

[Lorenzo Miniero <[e-mail]>]

On Wed, 15 Sep 2021 11:49:19 +0200
Juliusz Chroboczek <[e-mail]> wrote:

> >> To give an example of how this is done in production services: on
> >> Twitch, once you log in, you go into account management, click on
> >> the "Stream" tab, and copy a really long string of junk out of a
> >> field labeled "Primary Stream Key." You paste this into your
> >> broadcast client in a field usually named "Stream Key."  
> 
> Just to be clear: I think token auth is a good idea, and as a matter
> of fact Galene uses token auth for authentication to the TURN server.
> 
> What I'm arguing for is a simple, interoperable user/password
> mechanism for the simple case, for when the infrastructure required
> to securely communicate the token to the client is not deemed
> necessary.  My current opinion (likely to change as Sergio and Adam
> explain stuff to me further) can be summarised as:
> 
>   * HTTP basic: MUST implement in clients, MAY implement in servers;
>   * token: SHOULD implement in clients, SHOULD implement in servers.
>   
> This way, server authors are guaranteed to interoperate with all
> clients if they choose to implement HTTP Basic, and they can use the
> more secure token auth if they are willing to put it the work
> required to build the infrastructure required to communicate tokens
> to their chosen clients.
> 
> This way, WISH is useful both for Millicast, whose business model
> relies on helping users deploy their high-quality broadcasting
> solutions, and for free servers such as Galene, who want to minimise
> the amount of hand-holding that they need to provide to their
> non-specialist users, even if that implies not using the most secure
> authentication techniques available.
> 
> -- Juliusz
> 


I personally think that would actually needlessly complicate things.
Using Bearer tokens in WHIP right now is as easy as adding an HTTP
header in the client, and reading it in the server: that's what my
prototypes (who know nothing of oauth) do, so very trivial to implement
and seems to be working just fine in my interoperability tests with
Sergio.

Any other authentication mechanism implemented by services (including
Basic Auth) could be reused anyway, as they can be what's used in a
custom API to, e.g., generate the unique token you'll then use in the
WHIP client (and check in the server).

Lorenzo

-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero