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

Aaron Parecki <aaron@parecki.com> Mon, 17 May 2021 20:56 UTC

Return-Path: <aaron@parecki.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 6EB323A44A3 for <oauth@ietfa.amsl.com>; Mon, 17 May 2021 13:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
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 kpxbS9ywZZyI for <oauth@ietfa.amsl.com>; Mon, 17 May 2021 13:56:35 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 79EC73A44A1 for <oauth@ietf.org>; Mon, 17 May 2021 13:56:35 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id z24so7230990ioi.3 for <oauth@ietf.org>; Mon, 17 May 2021 13:56:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2zyDhM1Bz1J3b02LriQkVCQBWnstFX+h+OaDIORA5gs=; b=iSlUir0J+3c8mKLMLCdZEdjHqIZcu7e2Zh7V7jtZ3j1630TnuPep09MqsakBDpGAu6 4uwvEzRsTmXIej5iV9TdEgjQXInHw7vuj18glDbnVsabfRNhIgrfF1j/uOdb5HLC9aY7 8uSb5MwXxZTkOZBUx/Lpad+wHCbcr4qfyK8inEds8u/njnevLSOHaXp4ejjNmr6+o8sT 22ohsjbOff0xqig2PFT03AXTNK/zyPKAe/++xGDDh4L7FYPZJQW+mcD4m7My8HZukfb4 ISxB/zVY4n7tgkFu+gAT9aq+2BPIwhClktDIcR5GWsjdB5wfjaQ2zndT9faJVnBxSWYH P4Rw==
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=2zyDhM1Bz1J3b02LriQkVCQBWnstFX+h+OaDIORA5gs=; b=D6aCUbAS/YSrGSICdmr3T1t6H7Yd9jGij+q7KYMtiLV4+QEcloWBw5yx/Ht1qaCspG xBhGk/K/2vm3EVotV3eQnY9G78X+qbqenpQLcQ+NjlNYYGyZ4LwaB718D4msE6tJ2QLe 5kJ3ou5HXx5IMmkZ+zmM8sLpo4LVJfoHa0hr0TZPLz/kbfY/s2wxryJO522g7IRW8slT M7Uu9grnWukzwKJ1ArUN1lnhMXV/YPLu8fTYVht9DVuWL8fspD3I+79mtR3pGlw9Kq+o zooIawZITrrdgayhHQMdOB4ICg7V1uEMdkbRERdbALDW+Vm0cSZPHB8o36dH3KanobEN xZvQ==
X-Gm-Message-State: AOAM5332N8RjWx/iUqiS2tZbpmwzsLylqGpi9is9+p0A1JcnGkUZoT98 F6Qy9ftIaIYqJEDmgu1r37YLJmt9+ENlNg==
X-Google-Smtp-Source: ABdhPJxs/sjROr1ACRNOsXLzE4aztt473VX+r4i1sGvIqgPvbYs2ZBHJ2cXgyk/wEDD0zGVNXtYHng==
X-Received: by 2002:a6b:8dd5:: with SMTP id p204mr1491434iod.195.1621284993331; Mon, 17 May 2021 13:56:33 -0700 (PDT)
Received: from mail-io1-f53.google.com (mail-io1-f53.google.com. [209.85.166.53]) by smtp.gmail.com with ESMTPSA id c8sm5389916ilk.29.2021.05.17.13.56.32 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 May 2021 13:56:32 -0700 (PDT)
Received: by mail-io1-f53.google.com with SMTP id t11so7205104iol.9 for <oauth@ietf.org>; Mon, 17 May 2021 13:56:32 -0700 (PDT)
X-Received: by 2002:a6b:f218:: with SMTP id q24mr1556802ioh.156.1621284992454; Mon, 17 May 2021 13:56:32 -0700 (PDT)
MIME-Version: 1.0
References: <CALAqi_8B7fv9j8CnqLt_wFKDbYLjmFci3jjeBz7EKpqKXu+Atw@mail.gmail.com> <1580CB36-826D-45B4-9073-0C7AF486FF32@pragmaticwebsecurity.com> <CAJot-L2fkiVUB+e2EL-fKuNRCZtvyHf0o7rtsGP2h70O=TjgoA@mail.gmail.com> <CA+k3eCTrJUdNVgvC-ZkOu9zfJgqeyc-dmGJ2Rtt7v2pY=pOdQA@mail.gmail.com> <CAJot-L0zKQc152bsXF0r5=2VjG+--aOJkEPU-kDFdMP0pd_vnA@mail.gmail.com>
In-Reply-To: <CAJot-L0zKQc152bsXF0r5=2VjG+--aOJkEPU-kDFdMP0pd_vnA@mail.gmail.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Mon, 17 May 2021 13:56:21 -0700
X-Gmail-Original-Message-ID: <CAGBSGjod1DC41HnFzK4mtcHK24ibpb3QjZh9tso5hDHsXTRy-g@mail.gmail.com>
Message-ID: <CAGBSGjod1DC41HnFzK4mtcHK24ibpb3QjZh9tso5hDHsXTRy-g@mail.gmail.com>
To: Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>, Vittorio Bertocci <vittorio.bertocci@auth0.com>
Content-Type: multipart/alternative; boundary="0000000000000e172705c28cd48c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kO78IUrTJtIT019LtkvR5uqbmf8>
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: Mon, 17 May 2021 20:56:41 -0000

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=
40rhosys.ch@dmarc.ietf.org> 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=
> 40pingidentity.com@dmarc.ietf.org> 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=
>> 40rhosys.ch@dmarc.ietf.org> 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 <
>>> 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
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>