[OAUTH-WG] thoughts on TMI BFF

Brock Allen <brockallen@gmail.com> Fri, 30 April 2021 17:00 UTC

Return-Path: <brockallen@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 73E673A1F8A for <oauth@ietfa.amsl.com>; Fri, 30 Apr 2021 10:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AsS7omN6cTRL for <oauth@ietfa.amsl.com>; Fri, 30 Apr 2021 10:00:36 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 392483A1F89 for <oauth@ietf.org>; Fri, 30 Apr 2021 10:00:36 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id q127so12194817qkb.1 for <oauth@ietf.org>; Fri, 30 Apr 2021 10:00:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:date:message-id:subject:from:to:user-agent; bh=+uCwZsBwFMP+a36f7cIMfDyij0p+pPfs/cXb8A2OfdM=; b=okGDObeX6uXeF0/x2s0VfDMslxoxsaljFYo2c89PYIFvntaBottTGArxwsv5VQuyT7 FdeQeJQ7a00VyZhm/p7w/i2uqfLcs768Bq95FdednpH9ITivfGgXVnaPzIfDFlB7qpxY G0p432FEhj+H7nF1SAmYHWNmOjJ//pq+kzF/xdMGoTOZRjGWMgCxWaE1JtlYWB5YmcsZ rK8Kd1r2nYeC/njXvxIN4+/JGUSFO2GNYr99x032m4Ov9/owQisKnAXGkNG8q8GHrHCB lRoKVQy30hYUyrMn8R6tL73Nn4vxDDjjf2W3X3OJDrHFYnVCIdguG5d3fbFTrtQFFIF6 WKxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :user-agent; bh=+uCwZsBwFMP+a36f7cIMfDyij0p+pPfs/cXb8A2OfdM=; b=idKPpHkZdVKpOeQCU9q9iGz2P+km1kqdK8lTSi/sIwSLmHTtBCdoxrIy3nkHI1SGHW ozlg1BgQMi6gTuSkHOhRtYG5GGG5CFUgjxgtL5XY3R9PBU6Q6uD/FEbR0SjfskdcK4pj mErQdUjSmn35nD99iSXlyqjL9vh+ak8ViOq+7lP5DDEKAd+Ro6GirvY3/yA44v+xYh9A f7aWip6muVVow3OKfjQlrAvYPoVzHt1Ns8Cf8SScts4pMRvV0cWCrEFB5fjj1gvjDlVF AMzF8DgKON0ipg29kVEjWlRpl7nJyU2u2ZUEc/G5azW7RqDLmdJyzVVXo3DFXq5COiNS /yvA==
X-Gm-Message-State: AOAM531jQL+YoCT9+C9+/EUIRW9S82fJtCmVFZHpDVG/K+vuUi/fY4np yg3fquzQqwRm0jh+Ngx13T2Xp8zxvANACQ==
X-Google-Smtp-Source: ABdhPJwHETcM0gbkKOvjSem1t9eE6XlUlfi58il8Zm+fT7Zcybow9dxsF4XqkhqI17TuAMsTE3qExA==
X-Received: by 2002:a05:620a:1224:: with SMTP id v4mr6371142qkj.237.1619802033855; Fri, 30 Apr 2021 10:00:33 -0700 (PDT)
Received: from [] (pool-74-103-207-160.prvdri.ftas.verizon.net. []) by smtp.gmail.com with ESMTPSA id s190sm1869697qkc.40.2021. for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Apr 2021 10:00:33 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----=_NextPart_26098197.719678388644"
MIME-Version: 1.0
Date: Fri, 30 Apr 2021 13:00:33 -0400
Message-ID: <Mailbird-815c2b72-1a27-4133-b6a0-d7822931cc78@gmail.com>
From: Brock Allen <brockallen@gmail.com>
To: oauth@ietf.org
User-Agent: Mailbird/
X-Mailbird-ID: Mailbird-815c2b72-1a27-4133-b6a0-d7822931cc78@gmail.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/egzioIY6Zbl3JUditnXuXPdzfPY>
Subject: [OAUTH-WG] thoughts on TMI BFF
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: Fri, 30 Apr 2021 17:00:40 -0000

Hello all -- 

I just watched the recent OAuth WG Interim call on TMI BFF and had some thoughts/feedback.

First of all, thanks Vittorio and Brian for the effort and allowing this discussion. Given Vittorio's former employer I'm sure he's familiar with the "rude Q&A" process, so this feedback is with all due respect. :)

1) The guidance on the headers for the user/session endpoint is welcome and needed, and not only for this endpoint but any endpoints the frontend would be invoking. That kind of help is lacking in general in the industry. I didn't look at the specific headers mentioned, but it might be good to discuss xsrf issues and cookie prefix guidance as well.

2) The user/session endpoint feels a lot like authentication and session management related, which historically falls to OIDC, and so this feels a bit out of place in an OAuth RFC. Recall that the client might not have even authenticated the user, so what happens in that case? So for that reason it feels like this concept should not be here, but rather in an OIDC document.

If this is not the will of the committee, then it feels like the user/session endpoint doesn't go far enough. As Aaron suggested, perhaps there's some minimum set of claims to consider (especially if interoperability is listed as a requirement). But then that leads back to irreconcilable minutiae such as should we use "sub" and does "sub" mean user or client (to use as an extreme example). Also, why would "iss" make sense, if the backend is abstracting the protocol details. I know those were examples in the slides, but I can see those discussions being challen.. er... fun :)

Additionally, there should be other features covered such as how to handle session management such as inactivity expiration, initiating login and/or logout from the frontend (which might involve an id_token or at least a "sid" claim value for logout), and how to handle SLO notifications between the frontend and backend (which might involve sharing a session state value), and how to expose all those endpoints securely.

This obviously is a slippery slope of features (and all heavily leaning more into OIDC's area), but it feels incomplete if you're offering a framework for a frontend to work with a backend on "protocol related things" which is more than just getting an access token. If it's not all covered, then people will homebrew it which is what this effort is meant to curtail.

So, IMO, the user endpoint concept should be all or nothing. And if it's nothing in the OAuth WG, perhaps it should be brought up in an OIDF context.

3) If the user/session endpoint is removed from the document, then it leaves coverage on just the one endpoint to obtain access tokens. As I mentioned, the headers guidance is quite valuable but it's useful for almost any backend request. This all seems like perhaps it's better placed in the Browser Apps BCP instead.

4) Torsten's comments got me thinking about the renewal of the access token and how that can be quite coupled with the interaction with the API. Given this interaction it feels like it makes more sense to have those done together, rather than asking the frontend to marshal/broker that coordination between the API and backend. This somewhat defeats the goal of the document to simplify the code in the frontend. And this also suggests (to me, at least) that perhaps the better place for all that coupled coordination is in the backend with the reverse proxy style, but I digress.

I know another motivation for the document is that there are some set of applications have a performance requirement and can't afford the additional hop of the reverse proxy style. So if the frontend is doing that coordination between API and token renewal then it will add some more overhead to do that brokering, albeit infrequently. This is, arguably, a nit.

5) For me personally in all the consulting I've done helping customers use OIDC/OAuth over the past 7 years (since OIDC was released) I've never seen anyone trying to do it this way. I do believe that some people try this style, but I wonder if it's just because they don't know any better (so lacking guidance) or is it really because they're actively trying to mitigate the reverse proxy hop performance issue? If it's the former, then I don't agree that it makes sense to formalize a less secure approach when they simply need better guidance (which arguably is the "full BFF" approach), and thus the motivation for the document is slightly weakened (IMO).