Re: [Wish] Authentication for resource url

[Adam Roach <[e-mail]>]

On 9/14/21 10:22, Juliusz Chroboczek wrote:
>> I think this is root cause of the confusion, the client does not generate or
>> retrieve the token anyhow.
> I am increasingly confused.
>
>> The server/service makes it available to the user somehow (out of the scope of
>> this document) and the end user configures it on the client
> So what you are saying is that WHIP does not depend on OAuth2, but it does
> depend on some unspecified token provisioning protocol?


Not really. At least, not in the engineering sense of the word "protocol."

What you need to do is get tokens to the users (users! not clients!) 
somehow so that they can set up their client. Exactly how you do that is 
entirely up to you. You also need to get a WHIP URL to users somehow so 
that they can set up their client. How you do that is also entirely up 
to you in exactly the same way.

Once users get those two bits of information from you (URL and Token), 
they put them into a WHIP client, and are ready to broadcast.

The client has to understand enough about the URL to use it in an HTTP 
stack. The client has to understand nothing about the token.

How you generate the token is 100% up to you, as long as your service 
can look at it and (1) tell which account it corresponds to, and (2) 
validate that it is authentic. There are many ways to accomplish this, 
and which one you choose is entirely up to you. Sergio described many 
viable approaches in his earlier message.

[Technically, it is possible for you to encode one or both of those 
things into the URL itself and then leave them out of the token. I would 
recommend against that for reasons that I can go into in a different 
message; but I don't want to make this email too wide ranging.]

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." And then everything just works. 
The client doesn't know whether this long string is some kind of crypto 
token, a random string stored in a database somewhere, or something 
else. As a human, I can't tell either. The only thing that knows how to 
unpack that string into an account identifier and validate that it is 
authentic is Twitch itself.

You can do that, if you like. Or you can hand tokens out on slips of 
paper, if your users are patient. You can send them to users via Signal. 
Really, how you get tokens to users is entirely up to you. And that's 
the important point.

If there are some entirely uncircumventable, non-negotiable constraints 
that entirely prevent you from doing something like what I describe 
above, then you can technically meet the two requirements I mention by 
telling users something like "In the field that asks for an 
authentication token, enter your username, a colon character, and then 
your password." The client doesn't know or care that this is the format 
you're using; only your servers need to know that. And it has the same 
security properties as HTTP Basic Auth, so you're not losing anything 
over what you want to do. (There are reasons I wouldn't use basic auth 
in 2021, but how you secure your system is entirely up to you.)

/a