Hey, Tbh - I have a bit of a hard time to see why this requires a spec, if that is all you are aiming at. Wouldn’t that be just an extension to the “OAuth for web apps BCP?”.
All I can add here is - this approach would not work for any of our customer. Because their real motivation is to implement a more and more common security guideline these days - namely: “no JS-accessible tokens in the browser” - but this document doesn’t cover this. cheers ——— Dominick Baier On 16. February 2021 at 22:01:37, 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
