Re: [Wish] Authentication for resource url

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

As said in a different email, we are not mandating the usage of oauth2.

Anyway, in my implementation the token is a unique value that is matched
against database on the whip enpoint. Media servers don't have access to
that database.

It doesn't harm my implementation to receive y
the token on the media server, but not sure if we should mandate it if
there are no plans for using it.

Best regards
Sergio

El sáb., 11 sept. 2021 5:59, Adam Roach <[e-mail]> escribió:

> This is OAUTH, right? They might be different servers, but I would expect
> them to be the same audience (as OAUTH uses that term) -- implying that the
> same token would be applicable to both of them (if my understanding is
> correct).
>
> My relatively strong preference is to specify that the same token is used
> for the requests; and, that being the case, it's not clear what additional
> security properties you gain by putting a token in the URL path (but I'm
> not, strictly speaking, opposed to it -- I just don't see the value).
>
> /a
>
> On 9/10/2021 2:24 AM, Sergio Garcia Murillo wrote:
>
> The second method (returning an unique url) could be detailed on the
> security considerations, but sending the same authentication bearer token
> in both requests should be in the normative part.
>
> Somehow, I don't like any of both ideas, sending the same token in both
> requests doesn't feel appropriate as the idea is that the whip endpoint and
> the whip resource could be in different servers, so the token for the
> PATH/DELETE request is most probably irrelevant for the media server.
>
> But returning an unique url doesn't seem a very secure idea. Anyway, if
> anyone could get access to the resource url. On the other hand, if an
> attacker has access to the url in the http response, it would most probably
> have access to the data in the request (i.e. the token).
>
> What do you think?
> Sergio
>
> El mié, 8 sept 2021 a las 19:27, Juliusz Chroboczek (<[e-mail]>)
> escribió:
>
>> > I think we have the following options:
>> >  - Use the same mechanism/info as the initial request to the whip url
>> (i.e.
>> > sending the Authentication header with the same bearer token)
>> >  - Returning a randomized opaque unique url
>> >  - Allow using both?
>>
>> I think this is better left unspecified in the normative part of the
>> document, but should be explained in detail in the Security Considerations
>> section or in an informative appendix.
>>
>> -- Juliusz
>>
>
>
>