blog: architecture driven auth part 2 (TMB)#3949
blog: architecture driven auth part 2 (TMB)#3949sixhobbits wants to merge 32 commits intoFusionAuth:mainfrom
Conversation
sixhobbits
changed the title
| --- | ||
|
|
||
| # Questions for Kim | ||
| - Do we want to include competitor review table in part 3? Might be nice to advertise FA advantages. If so, might be good to include Ory Kratos/Hydra - it's the only truly free and open source alternative to Keycloak I found (unlike FA which is freemium) that seems to be a bit more powerful than Keycloak, so people would probably want to compare it. |
There was a problem hiding this comment.
We could potentially include a competitor table; at heart, as a DevRel person, I've always just kind of shied away from including that type of thing in written content, whereas the Marketing folks would definitely be like, "YES!" to a comparison table. I think it's probably fine to include one.
|
|
||
| # Questions for Kim | ||
| - Do we want to include competitor review table in part 3? Might be nice to advertise FA advantages. If so, might be good to include Ory Kratos/Hydra - it's the only truly free and open source alternative to Keycloak I found (unlike FA which is freemium) that seems to be a bit more powerful than Keycloak, so people would probably want to compare it. | ||
| - I have the same question as Zoe in your presentation. I didn't understand the answer given. BFF started as team organisation and efficiency thing (like microservices) but is now conflated with a security pattern. The BFF security pattern could more simply be called "not serverless pattern" or "backend tokens pattern". So I don't understand why we need to keep the original BFF pattern aim of one server per frontend. How does having only one server for multiple frontends negatively impact security? |
There was a problem hiding this comment.
So "BFF" for auth could really be called an "auth proxy." It's true that it's been conflated, but the draft spec calls it BFF, so BFF it is. The general idea behind one backend per frontend in the security context though is similar in terms of organization and isolation. One auth proxy backend per frontend ensures that there's a security boundary between apps: there's data isolation between users, sessions, and permissions of one app vs. another, if one app's OAuth is compromised, that compromise doesn't affect all the other apps, different security strategies can be implemented between apps if necessary (perhaps one app needs mTLS or DPoP and another doesn't), etc. Then of course, there's the API gateway situation that's classical of BFF pattern. If you add the security context: if multiple apps share the same auth proxy but use different APIs, then you're packing one backend with multiple API gateways that have different permissions/scopes/etc., that increases the attack surface for all apps.
| # Questions for Kim | ||
| - Do we want to include competitor review table in part 3? Might be nice to advertise FA advantages. If so, might be good to include Ory Kratos/Hydra - it's the only truly free and open source alternative to Keycloak I found (unlike FA which is freemium) that seems to be a bit more powerful than Keycloak, so people would probably want to compare it. | ||
| - I have the same question as Zoe in your presentation. I didn't understand the answer given. BFF started as team organisation and efficiency thing (like microservices) but is now conflated with a security pattern. The BFF security pattern could more simply be called "not serverless pattern" or "backend tokens pattern". So I don't understand why we need to keep the original BFF pattern aim of one server per frontend. How does having only one server for multiple frontends negatively impact security? | ||
| - Outer Wilds stickers! Very cool No newline at end of file |
There was a problem hiding this comment.
Haha, thanks! Alex Beachum actually reached out to me to request that I make a custom charm for his sister Kelsey (who wrote the game) for Christmas last year!
| - Successful attacks are short-lived if you follow best practices (link to OAuth 2.1 draft and explain, with summary link to https://maida.kim/oauth2-best-practices-for-developers), which include short timeouts on tokens. | ||
|
|
||
| ## When to use a TMB? | ||
| - Only if you cannot, or may not, call a resource server through a proxy (backend) server and must call it through the frontend directly. (Can't think of an example of this, I must go find or LLM one) |
There was a problem hiding this comment.
The spec only says this:
When considering a token-mediating backend architecture, it is strongly recommended to evaluate if adopting a full BFF as discussed in Section 6.1 is a viable alternative. Only when the use cases or system requirements would prevent the use of a proxying BFF should the token-mediating backend be considered over a full BFF.
Performance and latency costs could be a reason not to, such as in use cases like game or video streaming and realtime stuff (like collaboration tools like Figma).
Infrastructure can also impact this... like PaaS that are meant to deploy static sites.
But honestly, the one that would probably affect the most people is that, if you're using a third party auth server, many of them use TMB out of the box.
Edit: Token-Mediating Backend: An alternative to the BFF architecture
sixhobbits
changed the title
|
|
||
| ### TMB security | ||
|
|
||
| TMB is massively less secure than BFF because access tokens in the browser are vulnerable to exfiltration by malicious JavaScript packages and cross-site scripting (XSS). However, it's slightly more secure than serverless web apps, which use the Browser-Based OAuth Client (BBOC) architecture, as they have no secure backend at all. |
There was a problem hiding this comment.
| TMB is massively less secure than BFF because access tokens in the browser are vulnerable to exfiltration by malicious JavaScript packages and cross-site scripting (XSS). However, it's slightly more secure than serverless web apps, which use the Browser-Based OAuth Client (BBOC) architecture, as they have no secure backend at all. | |
| TMB is less secure than BFF because access tokens in the browser are vulnerable to exfiltration by malicious JavaScript packages and cross-site scripting (XSS). However, it's much more secure than serverless web apps, which use the Browser-Based OAuth Client (BBOC) architecture, as they have no secure backend at all. |
| **The authentication flow** is hand-coded in this example to make it understandable and explicit, but in reality you should use a library like [Passport.js](https://www.passportjs.org/packages/passport-oauth2) to do most of the OAuth 2 work. Passport handles only the interaction between your backend and FusionAuth, not between your backend and your frontend. The important part of TMB that Passport leaves to you is getting session management correct (`utils/session.ts`) and separating the refresh token on the server from the access token returned to the browser. | ||
|
|
||
| **The frontend project** is very simple. Its only dependency is the React.js ecosystem, and authentication is handled manually in `services/AuthContext.jsx`. Since the FusionAuth webpage redirect handles login, the only authentication work the frontend needs to do is check whether the user is logged in and get new access tokens. | ||
|
|
There was a problem hiding this comment.
I think there's a little bit missing here about what the frontend does with the access token. Adding a bit clarifying that the access token is used by the frontend to call APIs directly (instead of proxying through the backend) is important, because it's the key functional difference between BFF and TMB.
In this way, the frontend can directly call both same-origin and cross-origin APIs.
|
Note: Since I'm not a CODEOWNER anymore, I can't officially approve PRs. Once comments are addressed, someone from the FusionAuth DevRel team should be pinged to approve. |
Co-authored-by: Kim Maida <yi.mihi@gmail.com>
Consistency edit
5 participants
No description provided.