blog: architecture driven auth part 2 (TMB) #3949
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
5 participants
No description provided.