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....@dmarc.ietf.org> wrote: > > > > On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt < > tors...@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.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
