I couldn't disagree more strongly; you will screw this up if you roll your own. The only secure option is to push as much as possible outside of your infrastructure. The concerns that it won't be "auditable" or that you "give away the keys to your kingdom" are nonsense and implementation-specific. If it's important, then don't build your integration with those flaws. You will still have substantial control, so you can decide how "auditable" the auth actually is and what to do with users authed from one platform or another.
If you can avoid managing authn, you will be substantially better off. I don't think you can so easily do this for authz; however, it depends on what you're building.
> you will screw this up if you roll your own. The only secure option is to push as much as possible outside of your infrastructure.
In my experience the integration with outside infra (OAuth, OIDC etc.) carries significant complications in itself, and Im not convinced that you really gain that much in terms of reducing complexity or attack surface by using these technologies. See this article that was on the front page yesterday for an example of non-obvious things that can go wrong https://trufflesecurity.com/blog/google-oauth-is-broken-sort...
> Im not convinced you really gain that much in terms of reducing complexity or attack surface by using these technologies.
In the case you mention (which I posted), integration of some kind offers functionality that would be otherwise impossible to get--single sign-on which lowers friction of user acquisition. SAML is one alternative method, but from my experience it has some sharp edges too.
Of course, whenever you're integrating a third party solution, you need to do so carefully.
If you can avoid managing authn, you will be substantially better off. I don't think you can so easily do this for authz; however, it depends on what you're building.