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

Philippe De Ryck <philippe@pragmaticwebsecurity.com> Sun, 16 May 2021 07:26 UTC

Return-Path: <philippe@pragmaticwebsecurity.com>
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 707D73A306F for <oauth@ietfa.amsl.com>; Sun, 16 May 2021 00:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=pragmaticwebsecurity.com header.b=WLfVres5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L/CuI1uc
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 pYdEZGkHqcnj for <oauth@ietfa.amsl.com>; Sun, 16 May 2021 00:25:58 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7390E3A306C for <oauth@ietf.org>; Sun, 16 May 2021 00:25:58 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 85EEFFC5; Sun, 16 May 2021 03:25:56 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 16 May 2021 03:25:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm1; bh=FOCMpt5IJyvNQnlggVcXHnulRHC/7t02IVRmS2HuZJc=; b=WLfVres5EfJ9 aTBHM0MjC9Efz07L3L3vhchQ2fPS7w7HAfOCenmxbO6H4Wc+iVkGgcHIOreet8D0 l519EHV9OxovYnJ2Ktaqq/tqgaFajRd5lEB/lbiFA7XvOCQjl2/a8exOXD2KEWBL NGu1tiQC6MwSuhnNDHs2oygSpLMVVEii0hyxb6LIrgdXk/bp6LEC4I+mf77vHvr2 Vxk0qAK0a5AOde5Q9HmfObsGxiQywOGz0ORadLfqWIUyOpN9CgzihhDTSulNVIBW Dop/NKavNSBxmHlqrvs60st8GmqqV+//VppHAihK3Lj77erKJ50vQ4YQc+SA771w F5E2Sm1iiQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=FOCMpt 5IJyvNQnlggVcXHnulRHC/7t02IVRmS2HuZJc=; b=L/CuI1ucNCgByQFSW2Vn8H L1Y3l2Zj2sSqNQocgWPddc06cbsqqqvAwZ8d06C2dnv3oE6j356qo42YEMs+bsvn PDDxirST5D0RLFzUXpRgPu2DM7lu+Ujnq1zJ8/3Iru5N+cg5aADW+u8Hrp3bjy7X JugnjB/tjFTvTziCPxPcM26ekighOo32hnTvqltI3ERkv/Er9t+d/DjJ4vH+8uK1 t5VM5HXQM0vxKvRAZNO5XpFYrioty5LNWAqSickTG9GxmRPfmXwnwt9trGRrtC4T SDrvyQcVdCHdmYYV4WlBZ7dAexqXvSp+yaIr6uqjkGMhnRpR1f19b6cl2VGHBQCw ==
X-ME-Sender: <xms:A8mgYGNqFt0o9O4yr5Egtih9tkK-vqPkySGWAPPxyTqbk5Vo6TenPA> <xme:A8mgYE9aWnuhDeGKI2INwHKhbDLh8WOxT7MHd3VJ9aW0L8yax2s4Ai6Kde1ztN1Nd NcoLqv3BAgZQZxYJA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeivddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpefrhhhilhhi phhpvgcuffgvucfthigtkhcuoehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvggssh gvtghurhhithihrdgtohhmqeenucggtffrrghtthgvrhhnpeejkeeiudefheduheettdej ueelgefghfdujeelhfekjedvkeegueehveeguefgtdenucffohhmrghinhepshhtrggtkh hovhgvrhhflhhofidrtghomhdpphhrrghgmhgrthhitgifvggsshgvtghurhhithihrdgt ohhmpdiffehstghhohholhhsrdgtohhmpdhivghtfhdrohhrghenucfkphepkedurdduie egrdduvdelrdelheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvggsshgvtghurhhithihrd gtohhm
X-ME-Proxy: <xmx:A8mgYNTFz2zqtJeo2s_SOOvTpZmW-tFEdSpB711ipGZjTWkUWoSaHg> <xmx:A8mgYGsfh3wmpIMJ37ttvgvr1LFK9UU2P6tFTUkpsHUSI7M2fSIS-g> <xmx:A8mgYOdGqmg8Bfdi3T4PqD1Snvx1DNQMxo2Vvo3OQTelw-12lEmoAw> <xmx:BMmgYCGNvBRHuS0tvy8LVywJDv-Fosj1ss1iP5cj1mYWsDuszccSlA>
Received: from [192.168.1.47] (d51a4815f.access.telenet.be [81.164.129.95]) by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 16 May 2021 03:25:55 -0400 (EDT)
From: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
Message-Id: <1580CB36-826D-45B4-9073-0C7AF486FF32@pragmaticwebsecurity.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3461B756-B7CB-46F9-B1A7-145189B29C0C"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
Date: Sun, 16 May 2021 09:25:54 +0200
In-Reply-To: <CALAqi_8B7fv9j8CnqLt_wFKDbYLjmFci3jjeBz7EKpqKXu+Atw@mail.gmail.com>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>
To: Filip Skokan <panva.ip@gmail.com>
References: <CALAqi_8B7fv9j8CnqLt_wFKDbYLjmFci3jjeBz7EKpqKXu+Atw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/dTYDNcg59fUYDR7sE4tZwTul5RE>
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 07:26:05 -0000

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