search

oauth-wg / oauth-browser-based-apps

Best practices for OAuth in Browser-Based Apps
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps
Other
22 stars 12 forks source link

Add BFF advice for performance purposes #40

Closed emmanuelgautier closed 3 months ago

emmanuelgautier commented 4 months ago

As the Token Mediating Backend may be considered for performance reason sometimes, this PR shared an alternative solution. Most of the time, the resource servers are deployed with a proxy handling incoming request. Re-using those components may be a solution to not degrade security, not degrades performance, and be an alternative to use Token Mediating Backend pattern.

A not answered question in this PR is how to shared relevant informations to handle cookies decryption when applied. Does this RFC should handle this question?

philippederyck commented 4 months ago

You're absolutely right that there is a lot of freedom in deciding how to implement the BFF or TM-BFF pattern. If there are pre-existing architecture components that can handle some of the heavy lifting, you are definitely encouraged to do so.

With that in mind, it is important to note that neither the BFF nor the TM-BFF require actual changes on the part of the resource server. It received an access token before, and it still receives an access token now. The specifics of how you implement the handling of that access token are out of scope for OAuth in general, and for this document as well.

In a nutshell, I don't think this PR addresses a core issue or adds an in-scope clarification, so I would not include it.

emmanuelgautier commented 4 months ago

Thanks for your review @philippederyck. I agree with you, this is not a core issue but more a deployment advice as it already exist some in the draft.

This PR intends to add a reminder about this implementation freedom and avoid wrong choice with TM-BFF based on performance reasons.

As there exists some architecture where the performance is critical but still exists some misconception on how to implement BFF, the latency reason could drive the decision to choose TM-BFF instead of BFF.

Maybe the latency reason to choose TM-BFF can be removed to avoid confusion?

philippederyck commented 3 months ago

Maybe the latency reason to choose TM-BFF can be removed to avoid confusion?

I agree that this suggestion makes sense. I have made the necessary changes in #47.

@aaronpk if #47 is acceptable, this PR can be closed.

emmanuelgautier commented 3 months ago

I am OK with the new PR. Thanks for the rewording.