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

Warren Parad <wparad@rhosys.ch> Sun, 16 May 2021 08:04 UTC

Return-Path: <wparad@rhosys.ch>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C411B3A003F for <oauth@ietfa.amsl.com>; Sun, 16 May 2021 01:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjkxSdzSWjdG for <oauth@ietfa.amsl.com>; Sun, 16 May 2021 01:04:13 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B343A003E for <oauth@ietf.org>; Sun, 16 May 2021 01:04:13 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id b13so3131811ybk.4 for <oauth@ietf.org>; Sun, 16 May 2021 01:04:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j/hq6Ofd/ELQTyFpOpE1x+ryJ2gKcvsQ/bmprFE+cfw=; b=O07WtfNfqrVTkcQZ90YicXUqHZVLXfx2UqSF0ZeHgnaR7XxmuE5G0Mvoi56I2cc7iC ew9VR2/AmhFatUZhxrAUkW2ebfmoT4dHhH65duNUHODRh7BmqcTGqTr9IwsdK15quAqo SL2XrKlpQ+BMLgGTuxPJ6m6Y+UP9+Fnuw1UEIeTce0yWiiu6r7GjC9FttDVWZ8hw2DiK JQhY6RwsOpmaG/H998x3Edz2SAeFbu2TwdGZFvl75JRI6wAdSh0H2m4p/HU6OmNxU59R Zy4m0pnZoz/VqX1B+bbBHHqEzKOSnpSWFJmsx3SUrE/gTu7F8erbtAGH8gExgUVoUYOL DYEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j/hq6Ofd/ELQTyFpOpE1x+ryJ2gKcvsQ/bmprFE+cfw=; b=IMR1PciKtbNkZ1fyjq0b66qyZWleXjx6Z1dR6ymmrfbL2eBj5oWlVOjzgA9yGFYR8Y gLBZ6WPhTqjqx1YkUtwTrpFREI6yAOrMvGjOJSEC8kEiCN8Od5YgrPWZlQzuTAjfI0it EYgSaCG3psFa0mtl6FesKRPqzeiSbONTrD1G8k2Jg1qhgrUZXJ0kqbMLsEtfP3ueVZgE 4U66n7FkvJTFHqwAFU0BLb0OoWsRZmNckSau9Sa0JDUeWTrOVYRHQu9WqRYt0viZdKd3 P1L/b+pf22FbzfStSLrnsReXVufxT1oqEdrRQ+zNYJ9tR6yjBFeDP3lctBo7J/jGmC6v O71Q==
X-Gm-Message-State: AOAM531lPFhwaDKEXxSR+8X4YO2cpUoeOq47p0CWE4iyXVn6CA5t/j6x +lHLhU4UJkPKqIkf7hLb4Pt5gy7tOym7LArOcOCv
X-Google-Smtp-Source: ABdhPJwA3qSgZ4x4GP8Bc6MWhtkzSQa4/WYf5gScGQ5ZanqOIUNH11qOvVCj/FHn/F3Icc90XvH2QGg48Lek3NvEEiE=
X-Received: by 2002:a25:3357:: with SMTP id z84mr73573555ybz.260.1621152251907; Sun, 16 May 2021 01:04:11 -0700 (PDT)
MIME-Version: 1.0
References: <CALAqi_8B7fv9j8CnqLt_wFKDbYLjmFci3jjeBz7EKpqKXu+Atw@mail.gmail.com> <1580CB36-826D-45B4-9073-0C7AF486FF32@pragmaticwebsecurity.com>
In-Reply-To: <1580CB36-826D-45B4-9073-0C7AF486FF32@pragmaticwebsecurity.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Sun, 16 May 2021 10:04:00 +0200
Message-ID: <CAJot-L2fkiVUB+e2EL-fKuNRCZtvyHf0o7rtsGP2h70O=TjgoA@mail.gmail.com>
To: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
Cc: Filip Skokan <panva.ip@gmail.com>, Vittorio Bertocci <vittorio.bertocci@auth0.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001a24d905c26dec04"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/I0EdJ8guQ3MwThvXSnH-ajX5x28>
Subject: Re: [OAUTH-WG] TMI BFF - html meta tags over/alternative to discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 May 2021 08:04:19 -0000

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 <
philippe@pragmaticwebsecurity.com> 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 <panva.ip@gmail.com> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>