I think the request is more for guidance about how to do it right.

I’ve been trying to find some guidance too, specifically for authentication with B2B and how to be adaptable to work with different IAM/SSO platforms

Having built a number of these, it's not that simple. For example do you put a tenant column on every table, have a separate table per tenant, or have a separate schema or database? There are tradeoffs for each approach and lots of gotchas you wouldn't expect. Like if you use a separate table or database, migrations take forever, you can run into file descriptor limits in your database, etc.

Separate table per tenant? Not unless you have/expect 2 to 5 tenants otherwise you run into the issues you describe above.

Having a database per tenant has always interested me. It make sense if the databases will be different (contain other tables)

Adding a tenant id to the tables that require them makes sense.

The best approach is to create a pivot table between users and tenants that holds user_id and tenant_id. Use the primary id of that table to represent the user at that tenant.

The limit is a lot higher than 2 to 5, but I think sooner or later it will get you. Until then you will suffer a slow death by a thousand migrations.

A separate database is best used if you need an absolute firewall between the tenants for security reasons. Almost no bug can ever let one tenant see the data from another. If they share tables, it's easier to make that mistake.

The downside is you can't have quieres across all your tenants, so you'll want a BI database that brings all the data together anyway.

That's true, but just looking at the code of some example application you've found online won't shed any light on what those trade-offs are.

Probably not, but there are articles on the subject that are helpful. I've found them before.

This leads to answer, which is: just start building, whatever option you will choose you will run into gotchas.

So no point of overthinking it.

That there are tradeoffs with each option does not mean all options are equal at all.

Doing a little research first, and thinking about which tradeoffs matter most in your particular case could save you a lot of effort rewriting things down the road.