Re: [Wish] Authentication for resource url

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

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

> > 1. concrete example comparing how it can be used as an alternative to
> > username/password. (http basic auth alternative)
>
> It's not about giving an example, it's about giving a normative way of
> using username/password with WHIP.
>
> For better or worse, Galene uses username/password for authentication, as
> does every other videoconference server known to me.  If a user know the
> group URL and their username/password, they can use Galene.  I want them
> to be able to access Galene over WHIP, and while I'm happy to write extra
> code (which needs only be done once), I don't want to do any extra
> per-user setup (which needs to be done once per user).
>
> If there is a normative way of using bearer tokens with password auth,
> then please give us the RFC number so we can implement it.  If there is
> none, then I suggest we make HTTP Basic mandatory to implement in clients.
>
>
Using an username and password for authentication is very limited and for
sure does not cover all the use cases for whip. Maybe on your
implementation that username and password was just used for the
conferencing solution, so a simple solution works for you.

However there are a lot of cases when a username and password is clearly
inefficient and not fit for the job:

- Using third party authentication: many web pages allows to log in using
external account (google, facebook, github), in this case you may not even
have an username and password for that account, or are you going to ask
someone to introduce their google mail and password in you encoder to be
able to stream it?.
- The account is used for much more than just the streaming service and
they would allow you to log into your service and perform a lot of
operations on your behalf. Would you be comfortable giving your credentials
to an external only service that could be hacked and your password exposed
in the wild?
- Most of the time the streaming service is not used by a single person,
each person having a unique login but sharing the account, which
credentials would you use in that case?

That's why most rest apis are using token authentication instead of just
using the username/password for the service. Even more, for example
github does not even allow you to use your username and password anymore on
git clients with ssh but you have to create an app token as secret in order
to prevent your account from being compromised if that info is leaked.

The actual value and format of the token is completely service specific and
we don't need to specify it. As a service provider you have a wide range of
options:


   - Generate a unique random token, associate it to a stream/account on
   your service and persist it on db or similar, then use a generic url
   /whip/endpoint for all the requests and retrieve the stream info associated
   with the bearer token from the db.
   - Generate a signed jwt containing the stream/account information which
   does not require to be persisted on the db,  then use a generic url
   /whip/endpoint for all the requests and extract the stream info from the
   jwt once the signature is validated
   - A variation of this would be to put the token on the url itself
   /whip/endpoint?token=${token} and not use a bearer token at all
   - Generate a custom token (like base64(${username}:${password})),  then
   use a generic url /whip/endpoint for all the requests and extract the
   stream info from the token. [insecure]
   - Put the username in the url /whip/endpoint/${username} and use the
   password as token [insecure]
   - use oath2, 2fa,...

Best regards
Sergio