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

From: Filip Skokan <[email-masked]>
Date: Sat, 15 May 2021 17:35:29 +0200

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*

---

From: Dick Hardt <[email-masked]>
Date: Sat, 15 May 2021 08:41:09 -0700

As I said in the meeting, I think this is an interesting idea that is worth
exploring.

I don’t think we need to resolve this for WG adoption of the document.

On Sat, May 15, 2021 at 8:36 AM Filip Skokan <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Evert Pot <[email-masked]>
Date: Sat, 15 May 2021 11:57:38 -0400

On 2021-05-15 11:35 a.m., Filip Skokan wrote:
> 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.
>
> 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.
>
> 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.
>
> 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.

A more appropriate HTML tag might be the <link> tag.

You would just need to register a link relationship in the IANA registry:

https://www.iana.org/assignments/link-relations/link-relations.xhtml

---

From: Philippe De Ryck <[email-masked]>
Date: Sun, 16 May 2021 09:25:54 +0200

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 <[email-masked]> wrote:
> 
> 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>.
> 
> 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.
> 
> 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

---

From: Warren Parad <[email-masked]>
Date: Sun, 16 May 2021 10:04:00 +0200

I agree, missing context for this:

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 <
[email-masked]> 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*

---

From: Julian Reschke <[email-masked]>
Date: Sun, 16 May 2021 11:12:07 +0200

Am 15.05.2021 um 17:57 schrieb Evert Pot:
> ...
> ...

And that way, it could be sent in a Link response header field as well.

Best regards, Julian

---

From: Brian Campbell <[email-masked]>
Date: Mon, 17 May 2021 14:03:30 -0600

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.

-- 
_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._

---

From: Warren Parad <[email-masked]>
Date: Mon, 17 May 2021 22:52:48 +0200

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=
[email-masked]> wrote:

>> Wouldn't this only be used as input to a SDK, why wouldn't you just
>> define the configuration in javascript, like everything else?
>>
>>> 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.
>>>
>>> discovery. HTML <meta> Tags
>>> <https://www.w3schools.com/tags/tag_meta.asp>.
>>>
> *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.*

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 17 May 2021 13:56:21 -0700

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=
[email-masked]> 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
>>>> 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.
>>>>

---

From: Warren Parad <[email-masked]>
Date: Mon, 17 May 2021 23:04:52 +0200

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

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

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

>>>>> think this could be the primary place an SDK would look at as it doesn't
>>>>> require any upfront external requests.
>>>>>
>>>>> I think it can save the group a lot of time defining a client discovery