Re: [OAUTH-WG] TMI BFF - html meta tags over/alternative to discovery

[Warren Parad <[e-mail]>]

Huh, why? It sounds like you are saying we want:

[image: image.png]

Just so that the SDK developer can write in their code:
document.getElementById...

They can already write a library that works with any backend by providing
these urls as input into the SDK. Not to mention input into the SDK is a
sane place to put the urls. You'd have to justify that putting the
configuration into the input of the SDK is actually non-obvious. But I
haven't seen that discussion yet.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Mon, May 17, 2021 at 10:56 PM Aaron Parecki <[e-mail]> wrote:

> Not exactly. The thinking is by standardizing these endpoints in some way,
> it would allow client library developers to write generic libraries that
> can work with any backend.
>
>
> On Mon, May 17, 2021 at 1:53 PM Warren Parad <wparad=
> [e-mail]> wrote:
>
>> I can't follow the discussion. So I'm still missing why the endpoints
>> would need to be listed anywhere. Isn't the developer of the html page, the
>> same developer that will configure the HTTP request to go to the backend?
>>
>> Warren Parad
>>
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement
>> Authress <https://authress.io/>.
>>
>>
>> On Mon, May 17, 2021 at 10:04 PM Brian Campbell <bcampbell=
>> [e-mail]> wrote:
>>
>>> The interim discussion can be found here
>>> https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-09-oauth#Discussion
>>> but the general context, as I understand it, is that there's a desire to
>>> have the location of the two application endpoints be conveyed to the
>>> frontend in a defined way that avoids out-of-band configuration and also
>>> doesn't infringe on the application namespace. The current draft places the
>>> two endpoints directly in .well-known but a number of folks have stated
>>> reasons that's less than ideal or even unworkable in many common
>>> deployments. Moving to a single static document in .well-known that lists
>>> the endpoint locations is one alternative approach. This thread suggests a
>>> different alternative of placing the locations in HTML meta/link tags or
>>> link headers returned with the application's main html page.
>>>
>>>
>>> On Sun, May 16, 2021 at 2:04 AM Warren Parad <wparad=
>>> [e-mail]> wrote:
>>>
>>>> I agree, missing context for this:
>>>>
>>>> As discussed in the interim, a well known set of endpoints (or even a
>>>> single root client discovery document) might not always be available for
>>>> control to the webpage depending on where and how it is hosted, on the
>>>> other hand the HTML it serves always, I hope, is.
>>>>
>>>> Wouldn't this only be used as input to a SDK, why wouldn't you just
>>>> define the configuration in javascript, like everything else?
>>>>
>>>> Also, is it required or something that can be added later?
>>>>
>>>> On Sun, May 16, 2021, 09:26 Philippe De Ryck <
>>>> [e-mail]> wrote:
>>>>
>>>>> Without having the full context of the interim meeting, this feels
>>>>> really off to me. I see the need for making this configurable, but I have
>>>>> doubts about using HTML elements for this purpose.
>>>>>
>>>>> As far as I understand, this mechanism is supposed to be used for
>>>>> modern frontends (Angular, React, …). Having to add variables to the
>>>>> index.html in these applications is likely to conflict with their
>>>>> development paradigms. It would be much easier to add these variables to
>>>>> the environment file, so you can differentiate between dev and prod when
>>>>> necessary.
>>>>>
>>>>> Additionally, querying the DOM for API endpoints sounds like a lot of
>>>>> trouble. I don’t think that injection is that big of a risk, but I might be
>>>>> wrong (I’m sure someone said that about the base tag as well). However,
>>>>> using DOM APIs like this will cause headaches for server-side rendering,
>>>>> where these DOM APIs are typically not available (e.g.,
>>>>> https://stackoverflow.com/questions/62896223/is-there-a-way-to-access-dom-serverside
>>>>> ).
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Philippe
>>>>>
>>>>> —
>>>>> *Pragmatic Web Security*
>>>>> *Security for developers*
>>>>> https://pragmaticwebsecurity.com/
>>>>>
>>>>>
>>>>> On 15 May 2021, at 17:35, Filip Skokan <[e-mail]> wrote:
>>>>>
>>>>> Hello Vittorio, Brian, everyone
>>>>>
>>>>> This is a followup to my feedback in the TMI BFF interim meeting on
>>>>> April 26th where I mentioned I'd bring this to the list for discussion.
>>>>>
>>>>> I proposed an alternative to using fixed endpoint locations and/or
>>>>> discovery. HTML <meta> Tags
>>>>> <https://www.w3schools.com/tags/tag_meta.asp>.
>>>>>
>>>>> These would be in the returned page HTML's head tag, e.g.
>>>>>
>>>>> <meta name="oauth-bff-token" content="/api/bff-token">
>>>>>> <meta name="oauth-bff-sessioninfo" content="/api/bff-sessioninfo">
>>>>>
>>>>>
>>>>> The javascript SDK handing TMI BFF would know to look for these
>>>>> defined meta tags to source the location of the different endpoints. I
>>>>> think this could be the primary place an SDK would look at as it doesn't
>>>>> require any upfront external requests.
>>>>>
>>>>> For the SDK this is as simple as
>>>>>
>>>>> var bffTokenPath =
>>>>>> document.querySelector('meta[name="oauth-bff-token"]').content;
>>>>>
>>>>>
>>>>> If this was the only mechanism defined by the document (to be bashed)
>>>>> I think it can save the group a lot of time defining a client discovery
>>>>> document which would be otherwise needed. If discovery as an alternative
>>>>> solution is indeed inevitable, it can be a second in line mechanism the
>>>>> javascript SDK would know to use.
>>>>>
>>>>> As discussed in the interim, a well known set of endpoints (or even a
>>>>> single root client discovery document) might not always be available for
>>>>> control to the webpage depending on where and how it is hosted, on the
>>>>> other hand the HTML it serves always, I hope, is.
>>>>>
>>>>> Best,
>>>>> *Filip Skokan*
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>