Hello all -- I just watched the recent OAuth WG Interim call on TMI BFF and had some thoughts/feedback.
First of all, thanks Vittorio and Brian for the effort and allowing this discussion. Given Vittorio's former employer I'm sure he's familiar with the "rude Q&A" process, so this feedback is with all due respect. :) 1) The guidance on the headers for the user/session endpoint is welcome and needed, and not only for this endpoint but any endpoints the frontend would be invoking. That kind of help is lacking in general in the industry. I didn't look at the specific headers mentioned, but it might be good to discuss xsrf issues and cookie prefix guidance as well. 2) The user/session endpoint feels a lot like authentication and session management related, which historically falls to OIDC, and so this feels a bit out of place in an OAuth RFC. Recall that the client might not have even authenticated the user, so what happens in that case? So for that reason it feels like this concept should not be here, but rather in an OIDC document. If this is not the will of the committee, then it feels like the user/session endpoint doesn't go far enough. As Aaron suggested, perhaps there's some minimum set of claims to consider (especially if interoperability is listed as a requirement). But then that leads back to irreconcilable minutiae such as should we use "sub" and does "sub" mean user or client (to use as an extreme example). Also, why would "iss" make sense, if the backend is abstracting the protocol details. I know those were examples in the slides, but I can see those discussions being challen.. er... fun :) Additionally, there should be other features covered such as how to handle session management such as inactivity expiration, initiating login and/or logout from the frontend (which might involve an id_token or at least a "sid" claim value for logout), and how to handle SLO notifications between the frontend and backend (which might involve sharing a session state value), and how to expose all those endpoints securely. This obviously is a slippery slope of features (and all heavily leaning more into OIDC's area), but it feels incomplete if you're offering a framework for a frontend to work with a backend on "protocol related things" which is more than just getting an access token. If it's not all covered, then people will homebrew it which is what this effort is meant to curtail. So, IMO, the user endpoint concept should be all or nothing. And if it's nothing in the OAuth WG, perhaps it should be brought up in an OIDF context. 3) If the user/session endpoint is removed from the document, then it leaves coverage on just the one endpoint to obtain access tokens. As I mentioned, the headers guidance is quite valuable but it's useful for almost any backend request. This all seems like perhaps it's better placed in the Browser Apps BCP instead. 4) Torsten's comments got me thinking about the renewal of the access token and how that can be quite coupled with the interaction with the API. Given this interaction it feels like it makes more sense to have those done together, rather than asking the frontend to marshal/broker that coordination between the API and backend. This somewhat defeats the goal of the document to simplify the code in the frontend. And this also suggests (to me, at least) that perhaps the better place for all that coupled coordination is in the backend with the reverse proxy style, but I digress. I know another motivation for the document is that there are some set of applications have a performance requirement and can't afford the additional hop of the reverse proxy style. So if the frontend is doing that coordination between API and token renewal then it will add some more overhead to do that brokering, albeit infrequently. This is, arguably, a nit. 5) For me personally in all the consulting I've done helping customers use OIDC/OAuth over the past 7 years (since OIDC was released) I've never seen anyone trying to do it this way. I do believe that some people try this style, but I wonder if it's just because they don't know any better (so lacking guidance) or is it really because they're actively trying to mitigate the reverse proxy hop performance issue? If it's the former, then I don't agree that it makes sense to formalize a less secure approach when they simply need better guidance (which arguably is the "full BFF" approach), and thus the motivation for the document is slightly weakened (IMO). Thanks. -Brock
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
