3 ms·

Or just use your favorite oauth / oidc library. AuthZero is for people that need SAML or AD integration or some other legacy tech.

• mooreds 4y ago
  That's a great path for many folks. I think building on a framework is far far better than rolling your own. However, often there comes a time when you have multiple applications that all need a shared user data store. (Note, I work for FusionAuth, so I am, to some extent, talking my book here.) You then have some choices: * run everything off of one app (both features and user management) and have other apps oauth/oidc into that app. This means that other apps are now dependent on one main app. Within that app, user data and feature data may get entangled * hive off the user manangement and login data from the main app to a separate one and have other apps oauth/oidc into that second app. This lets you deploy/manage them separately and still have one user data store. Congrats, you've just invented an auth server! This can be a good option, but that refactoring may be a bit painful, and you're on the hook for maintaining the auth server (dependencies, adding workflows and functionality). * stand up a separate auth server (or use a SaaS offering) and have apps oauth/oidc into it. In this scenario the auth server vendor is responsible for updates (adding new forms of MFA such as WebAuthn, for example) and your apps get the benefits from it. The issue here is that this is a core part of your app, so any downtime or integration issues due to an upgrade can cause major headaches. (At FusionAuth, we work around this issue with a single tenant model and by allowing you to pin your version.) It's engineering, so there's no perfect solution. The above are some of the tradeoffs I've seen.