IETF Logo Mail Archive

Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

Warren Parad <wparad@rhosys.ch> Sun, 14 February 2021 15:35 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 702103A0E0E for <oauth@ietfa.amsl.com>; Sun, 14 Feb 2021 07:35:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.187
X-Spam-Level:
X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 3hrcXbHrOWhe for <oauth@ietfa.amsl.com>; Sun, 14 Feb 2021 07:35:33 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 B21B53A0E0D for <oauth@ietf.org>; Sun, 14 Feb 2021 07:35:33 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id i8so55670iog.7 for <oauth@ietf.org>; Sun, 14 Feb 2021 07:35:33 -0800 (PST)
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=tavwzFq54ZA9aEZWYn/DTAWqnBWg/yDj2p7pxaf+blU=; b=cwK939l8sXWjwTeIJUHSB0cezLrF9j58tq/yX0Dj/o4RHjWHVQq3ZGwwk53k0F99gW lwnKm0kCBz9zRsIQV6cGvFoLF9IK2uM1TBTHS2Z7Oeeu0+InSYuFbdsMXTYJYPq8Mnue shseJFRvywzpyfAMt+93Hbbxe0um6fzvbRuumJ0Yzs8vFrazL68GrhwHa9LgrFjy6iOO m/fZ2Kh8Lngy4V/v5vNi/Xgd1hV7STukcAmOQ9onqN0zGAnpXROb3+UDHC2UEsAzpd/P n9KwB4iga7UNz70qF5Cd3FS3jDjsIIIy+T3hWxqL+qLJU5olGnPqXSRGDSf2OF/486ib bEdw==
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=tavwzFq54ZA9aEZWYn/DTAWqnBWg/yDj2p7pxaf+blU=; b=ZXE5IF5FjVPtnoKSKSK3T+q8+U+BlqzS+vXpeY13L3jY9TpR0Bo8F3V59rOeZCgTcn YrX4UESHUfEpCRb/mnfKfYPSMok9t3oVFzYmliz3DkRB3QHhPzun6yuludyn3ep+o2s6 H8Pyg1w9XIwCHZsid6JY0ytjCJ9RreYpsh3nsUXIfQfBOlC3DL7Hxs7DGBO3B4oGMHCd p4mg8UqxQUo5NEfoA+7SD0VmgMtKCixAkhKzyosLt2ympZpR33LA46+/ka4R/nfoQOXK +TB82Kxnp/MNoCPhCzsfRFZZqwfx0f5GfYiwRA2HuEN9+atAB8QyeN4wK137IO2BS+fq 4uvw==
X-Gm-Message-State: AOAM532cWiCMVK6Oa27YfHsmN6RZZeuPuFGvU0tvAI4CZKXZLdVDKTdG mb9lJC/84GAE/tOhYK8lSGE7kewMWkWP7lpP4Get
X-Google-Smtp-Source: ABdhPJyl6BCninotvnBfwp1gxzqFEwtWxKATyI8KS+tQ2WKUYLR3en3htAtKM9WnBksy2wMt554gTxlK3DRBbeRaQ6Q=
X-Received: by 2002:a02:3541:: with SMTP id y1mr11485921jae.66.1613316931646; Sun, 14 Feb 2021 07:35:31 -0800 (PST)
MIME-Version: 1.0
References: <CAGL0X-qvLz=gG06Q3mL5yNs5f-eqSwxO-g=K=cDKdmC8VP+UEg@mail.gmail.com> <AE8B3F28-D7B3-4A70-8E0D-2F673970E008@forgerock.com> <CAGL0X-o4Aq6Ec0UviqLryrxn0ksetLhjkVfVoNf_Cjtda+MX8g@mail.gmail.com>
In-Reply-To: <CAGL0X-o4Aq6Ec0UviqLryrxn0ksetLhjkVfVoNf_Cjtda+MX8g@mail.gmail.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Sun, 14 Feb 2021 16:35:20 +0100
Message-ID: <CAJot-L3BXNyM3L_74-W+y3cJzmG2UxPiovb3DHLbmBL66-53SQ@mail.gmail.com>
To: Stoycho Sleptsov <stoycho.sleptsov@gmail.com>
Cc: Neil Madden <neil.madden@forgerock.com>, Vittorio Bertocci <vittorio.bertocci@auth0.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009f112d05bb4d9e6b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Fyx4LZ3cw8Yp6lR-raFu6Fe-Iuo>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (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: Sun, 14 Feb 2021 15:35:35 -0000

redirect_uri and use PKCE via the code verifier.

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://authress.io>.


On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov <stoycho.sleptsov@gmail.com>
wrote:

> Thanks a lot for your answer Neil,
>
> as I am no expert (yet :-)) in security I was afraid to rely on
> redirect_uri for authentication of the client,
> but I will consider that option as more trustworthy now.
>
> (it is also not very clear for me which part of the app can be
> regarded as the redirect_uri owner, the BFF or the loaded frontend
> SPA, but maybe it is not so important)
>
> If you had the two options for authentication of the frontend SPA
> client - the redirect_uri on the one hand, and the Basic
> authentication with client secret through the BFF on the other, which
> one would you recommend?
>
> On Sun, 14 Feb 2021 at 16:28, Neil Madden <neil.madden@forgerock.com>
> wrote:
> >
> > Public clients are implicitly authenticated by their ownership of the
> registered redirect_uri. This why it’s important to use a redirect_uri for
> which ownership can be reasonably established, such as HTTPS endpoints with
> exact URI matching.
> >
> > There are more things that can go wrong with that (see the security
> BCP), but it can be made reasonably secure.
> >
> > — Neil
> >
> > > On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.sleptsov@gmail.com>
> wrote:
> > >
> > > 
> > > I would like to add my reasons about the "Why are developers creating
> BFF for their frontends to communicate with an AS",
> > > with the objective to verify if they are valid.
> > >
> > > I need the client app. to be authenticated at the AS (to determine if
> it is a first-party app., for example).
> > > If we decide to implement our client as a frontend SPA , then we have
> no other option except through a BFF, as PKCE does not help for
> authentication.
> > >
> > > Or is it considered a bad practice to do that?
> > >
> > > Regards,
> > > Stoycho.
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > --
> > ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
>

v2.23.0 | Report a Bug | By Email