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

Stoycho Sleptsov <stoycho.sleptsov@gmail.com> Sun, 14 February 2021 17:27 UTC

Return-Path: <stoycho.sleptsov@gmail.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 3A4EA3A1024 for <oauth@ietfa.amsl.com>; Sun, 14 Feb 2021 09:27:30 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=gmail.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 SUuJrrzpqY5z for <oauth@ietfa.amsl.com>; Sun, 14 Feb 2021 09:27:28 -0800 (PST)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 151C93A101C for <oauth@ietf.org>; Sun, 14 Feb 2021 09:27:27 -0800 (PST)
Received: by mail-ej1-x62e.google.com with SMTP id w1so7512247ejf.11 for <oauth@ietf.org>; Sun, 14 Feb 2021 09:27:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KjYUn0tYsMwZolnmD+fCxvCIZI3iaSOxz33trOLWVv8=; b=vIN0V9utVEgQ3oDBM78x2j2VlIAsiPvus1ZPOQErD1l6PmWFlo7XgWoeTxJ5q8hkzT VZLVJy10g2/LWonmW7Pp5R1RtTtSjid+6i2OnXLuEDRBUvEoFfHnssmwGn1WA5YXSwX1 pcd9y8c7rd9F4gUC7kk0AOyF4Hz+iiyJqDQzVMwUrJk7icC9tGSWzDEceLu7lPl7WxPX 5SS7bbi2I/ROxpCyR/JkzDLowFSPUcrevoFLeSWubbshcS4nxTaf7u3FHxhsNBUgVLSP OlO5MUjyAZxwQm+jrWAjWDp8GHpsN5f4kVwf2E87OeHe2nLDGE2qFxje3kDj6sl/pvjI HcWw==
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=KjYUn0tYsMwZolnmD+fCxvCIZI3iaSOxz33trOLWVv8=; b=U0Qh217i8/xjNIb1jXyu+sbvecwQE2xzK7sbToc/lxGYfKpKVkJ33pKD2UQBJBMCYp rpE0fyT6hdTFbTqpI3LazfNxoR+nVkukAv1hZSzgYqKJgRX6dkt1FXJN9hUX2Hp/DnLe VZxnkR0IPAZP9EwA1QkLLcDfXCfg/To3EUfLNMouMsjmuNPUx/TDB7JWLj/04hSC4Jch SO8LatcCcyThoY3wLschCgG/stkQ3v8m7efrCMj7YSfbcd2vg+dhNBIBavEFCvokYYiM p1pIJU/vRnnI55txV6K4Zk4UsovHp71B4IPxC0bmtjQyeNe0+I4MtxZnZvGxQfSnCrc0 5RwA==
X-Gm-Message-State: AOAM532IxvAOmSxRqa0EjgJXQms3F6W72LM+l9/SQko9IdX45xRaaVDv XQd58gHu0AOpDHcKqyvKj6TXF4smky6yHjaG3Nk=
X-Google-Smtp-Source: ABdhPJyiKVZBQAPDytsejP2XFuXzimpk9tx7TbdJdb/f3zAtTV5H3fr+/reO/WN7ivLzXzSR3nLG1lvKSXkuQzpkL5g=
X-Received: by 2002:a17:907:11c1:: with SMTP id va1mr3121208ejb.352.1613323646405; Sun, 14 Feb 2021 09:27:26 -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> <CAJot-L3BXNyM3L_74-W+y3cJzmG2UxPiovb3DHLbmBL66-53SQ@mail.gmail.com>
In-Reply-To: <CAJot-L3BXNyM3L_74-W+y3cJzmG2UxPiovb3DHLbmBL66-53SQ@mail.gmail.com>
From: Stoycho Sleptsov <stoycho.sleptsov@gmail.com>
Date: Sun, 14 Feb 2021 19:27:15 +0200
Message-ID: <CAGL0X-rwM4Kc4qQSea+gaO7YORZgnJTHWyFM3VPcaJ2ceX527A@mail.gmail.com>
To: Warren Parad <wparad@rhosys.ch>
Cc: Neil Madden <neil.madden@forgerock.com>, Vittorio Bertocci <vittorio.bertocci@auth0.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000da0e4f05bb4f2e31"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PhaGjhukRPVAiO3M-xPoheaWIWs>
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 17:27:30 -0000

Thanks Warren,

as I see you and Neil have the same idea,
but as of this moment I think this method is not a valid option for
authenticating
a client according to the draft-ietf-oauth-v2-1.

On the other hand, authenticating the client through the BFF
seems conforming to the spec., but in the case when the access token is used
in the browser in fact, I am afraid that it can be regarded as
some kind of "deception" of the AS.

It seems the frontend SPA is not the easiest way to go with oauth...

Stoycho.

On Sun, 14 Feb 2021 at 17:35, Warren Parad <wparad@rhosys.ch> wrote:

> 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>
>>
>