I'm building a portfolio that acts as a central authentication provider for several applications, so users can sign in through the portfolio instead of creating a separate account for every app—similar to "Continue with Google." I'm using Better Auth's OAuth provider plugin and have already configured the portfolio to register OAuth clients and issue a client ID and client secret. However, the documentation seems to focus mostly on the provider side. What configuration do I need in each client application to let users log in through my portfolio?
3 Answers
Since this is for user authentication, expose OpenID Connect rather than only basic OAuth. Start by requesting your discovery document at /.well-known/openid-configuration and verify that the issuer, authorization endpoint, token endpoint, and user-info endpoint are correct. Also check that the issuer and callback URL match the client configuration exactly. A common mistake is placing the discovery route under something like /api/auth/.well-known instead of exposing it at the expected path.
The provider plugin mainly handles the server side. In each client application, configure Better Auth’s generic OAuth support to use your portfolio just like any other external provider. Point it at your own authorization and token endpoints, and include a user-info endpoint if your provider exposes one. Make sure the redirect URI exactly matches the callback URL configured on the provider.
That was the missing piece. I configured the generic OAuth client and adjusted a few settings, and the login flow is now working.
Be careful with session cookies once you have multiple applications. If the provider and clients share cookies by setting them on a parent domain, they can interfere with one another. Refresh-token rotation can then cause confusing logouts when one application refreshes a token that another application still has cached. Keep cookies scoped to the specific host whenever possible. If your applications use completely separate domains, this particular cookie-sharing issue won’t apply, but you should still keep refresh-token handling isolated per client.
That was exactly my mistake. I had the discovery endpoint nested incorrectly under /api/auth/.well-known. After correcting the route and updating the client configuration, it worked.