For example, we started off with oathkeeper, we now have it running with ory cloud (kratos) (for authentication) on our new product, but the oathkeeper also has an integration into my existing homegrown "stack" (which is really an old PHP-based user management system, nothing fancy). It helps though and I can still use it. We also looked at hydra at some point, but with general direction, we haven't used it yet (for current or future developments). But my guess is that if we decide we need Oauth2, then it will probably what we go with, vs. another solution. Even though it doesn't have a fancy UI. Similar to Keto, still evaluating if we do that or maybe another Zanzibar-style project. Bottom-line, it's possible and feasible. May even do a more simple approach and e.g. build a similar API to Keto if we think it's too complex for our liking. There's literally no rush if you keep it somewhat clean and especially when requirements develop as you go vs. you have a 12 month roadmap ahead of you.

Stuff like OTP is nice to have per-subdomain, since we want some more protected. Currently using traefik basicauth as another layer of protection on administrative subdomains

We won't integrate with any cloud services, like social media accounts. We will integrate with a self-hosted forum, which will be part of the SSO setup

Does that make sense?

I'm thinking I can pull it all off with ory kratos

we dont need integration with other's services, just our own

Not sure how we're doing SSO yet... We have many duplicate accounts between 3 sister sites. We will try to find their accounts and concatenate them. Or perhaps we should let them do it ("connect accounts"?) Not sure.

Sounds like Johnathan, mentioning ‘3 sister sites’, also means/ needs multi-domain SSO.

So to make it symmetric, I'd have one hydra instance per site, and then one stand-alone kratos instance?

symmetric/coherent/de-coupled (I can't have situations where upgrades to one site affect the others)