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

Thanks Vittorio and Brian for starting this work: I have deployed this
pattern in the field on a number occasions, at security and tech savvy
organizations, on their request.
I'd describe it as a regular OAuth 2.0 web client with the addition of a
well known endpoint meant for in-browser (counterpart) clients.

Enterprise security architects seem to prefer this approach because of the
confidential client involved and the ability to outsource a perceived
cumbersome and security sensitive task to a backend
infrastructure component under direct control of the organization rather
than the end user. Even if there's no proven security advantage by letter
of the OAuth 2 spec, it may still be a preferred way of deployment for some
organizations because of the way they want to structure security sensitive
software, the way they deal with software development, and the way they
deal with application and infrastructure management.

I very much agree with all of the arguments Vittorio brought up before and
I really don't see any reason to reject this approach. It is very useful to
list the considerations about this architectural pattern and to give
guidance about when it can be used and when to avoid it, regardless of the
complexity or length of such a spec.

Hans.

On Tue, Feb 16, 2021 at 10:02 PM Brian Campbell <bcampbell=
40pingidentity.com@dmarc.ietf.org> wrote:

>
>
>
> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>> Thank you again for the explanation.
>>
>> I think your assumption about the overall flow should be described in the
>> draft.
>>
>
> We did attempt to capture the assumptions in the draft but clearly could
> have done a better job with it :)
>
>
>>
>> As I understand it now the core contribution of your proposal is to move
>> refresh token management from frontend to backend. Is that correct?
>>
>
>  Taking that a bit further - the idea is that the backend takes on the
> responsibilities of being a confidential client (client creds, token
> acquisition, token management/persistence, etc.) to the external AS(s). And
> TMI BFF describes a way for that backend to deliver access tokens to its
> own frontend.
>
> *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
>

-- 
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu