Depending on your use case, for example if you only have one application, you might be better off running something embedded in your app, or independent but using the same runtime/deployment environment. Then, when you are ready to add another app or integration, you should be able to introduce a standalone auth system more easily if appropriate (because all your auth interactions should be relatively standardized). I'm a big fan of standalone auth systems as a way to simplify access control and give a single view of a user/customer, but you can also succeed using open source embedded libraries.
When the moment comes to introduce a standalone system, you should consider a few dimensions (this list pulled from a previous comment of mine: https://news.ycombinator.com/item?id=26360048 ):
* open source or not
* standalone application or library/framework you integrate
* self hosted or SaaS
* authentication, authorization, user management or all three?
* standards coverage
* SSO support
* integrations with other auth tech (LDAP)
* which OAuth grants are supported
* cost
* operational complexity/support for your deployment environment
* specific features if needed (for example, customization of the look and feel with themes, or customization of the login flow with something like Keycloak's plugin system)
* documentation and developer experience
These dimensions all matter to varying degrees depending on your team and needs.Disclosure: I work for https://fusionauth.io/ which has open source supporting libraries and docs, but which is itself not open source.
EDIT: added cost, operational complexity and customization to the list.