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

[Stoycho Sleptsov <[e-mail]>]

Thank you for the comprehensive answer, Neil.

Initially I said that "I need the client app. to be authenticated at the
AS", and I meant authenticated as by the spec (explicit authentication).
It seems that the reason which I gave as an example to explain why would I
need that (to determine if it is a first-party app.), taken alone, is weak
to justify the decision for such a constraint as an explicit authentication.
And I thank you for that clarification.
But the question why would I (or somebody else) need the client to be
explicitly authenticated as a confidential client at the AS is a
different matter.
It is an important question, of course, and it would be very interesting
for me to understand what is the difference between the set of
architectural properties induced by an explicit authentication (credentials
by the spec), and the properties induced by an implicit (redirect_uri)
authentication, but I am afraid to not abduct the conversation away from
the original intent of the TMI-BFF.

The main point for me was to verify that for a proper (explicit) client
authentication we need to go through the backend, because PKCE doesn't help
for that.
Which means that a document like TMI-BFF could be very helpful while trying
to consider all the BFF options.

Regards,
Stoycho.


On Sun, 14 Feb 2021 at 20:30, Neil Madden <[e-mail]> wrote:

> Within the spec “client authentication” refers to explicit authentication
> of the client using credentials. But you said initially that you wanted
> this to “determine if it is a first-party app, for example”. You can
> determine this based on the redirect_uri and the fact that only the
> legitimate client can receive an authorization code at that redirect_uri
> (if its HTTPS, exact matching of URIs, etc). This is what I refer to as
> implicit authentication - the AS knows at the point of auth code exchange
> that only the legitimate client could have obtained that code.
>
> (This is not true for mobile clients using private-use URI schemes).
>
> Note that for both public and confidential clients, the confirmation of
> the client identity happens after the user has gone through the
> authorization flow. PAR fixes this for confidential clients, but not public
> ones. So that is one reason to prefer a BFF pattern and a confidential
> client.
>
> Confidential clients also have an extra layer of defence in depth: they
> need a redirect_uri *and* client credentials. So that is another reason to
> use a confidential client and BFF.
>
> A backend server may also have a more reliable connection to the AS. So
> that may also be a good reason to use a BFF - eg to avoid having to
> reauthorize with the user because an auth code or refresh request timed out
> due to a flaky network connection.
>
> So there may be many good reasons to use a BFF pattern. But if you just
> want a reasonable assurance of client identity at the point of issuing
> tokens, then IMO a public client + PKCE is fine for many cases.
>
> — Neil
>
> On 14 Feb 2021, at 17:27, Stoycho Sleptsov <[e-mail]>
> wrote:
>
> 
> 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 <[e-mail]> 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 <
>> [e-mail]> 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 <[e-mail]>
>>> 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 <
>>> [e-mail]> 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
>>> > > [e-mail]
>>> > > https://www.ietf.org/mailman/listinfo/oauth
>>> >
>>> > --
>>> > ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
>>>
>>
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>