Help me build a central auth server
I am making my portfolio as a central auth provider for all of my applications. So my users don't have to create account for each application. Instead they just continue with my portfolio. Just like "Continue with Google". I am doing this using Better-Auth…
I am making my portfolio as a central auth provider for all of my applications. So my users don't have to create account for each application. Instead they just continue with my portfolio. Just like "Continue with Google". I am doing this using Better-Auth oauth provider. I have setup my portfolio for this. Now I can register an oauth client and get the client_id and client_secret. But after reading through whole documentation I couldn't find how to make my client apps login with my portfolio. Do anyone has experience in this type of auth? Please help to do this.
Collected discussion
the plugin only builds the server half, thats why the docs feel like they stop halfway. on the client apps u point better-auths generic oauth plugin at ur own authorize and token urls, same as u would any external provider
pff
When I use generic oauth plugin for my client app it almost worked. Now I am doing some config tweaks. It make it work fully.
I am not going to host my client app under a parent domain. All of them are going to be under independent domains.
Yeah, that's the mistake I did. I exposed it in /api/auth/,well-know... and configured it in my client apps. Now it works.
Fair enough, that removes the shared cookie problem entirely. It does hand you the other one though: with the provider on its own domain, its session cookie is third party from every client app's point of view. Full redirects still work, since the provider reads its own cookie while you are on its domain. What breaks is silent renewal in a hidden iframe, which Safari has blocked for years. So plan the refresh path explicitly, a small backend per client holding the refresh token or an httpOnly cookie scoped to that client's own domain, rather than assuming you can re-auth invisibly.
On top of what xJSHAxx said, one trap that costs a day once you have several apps under one domain: scope the session cookies to the exact host, not the parent domain. If the provider and two clients all set cookies on .example.com they share them, and with refresh token rotation whichever app refreshes first invalidates the token the others are holding. It shows up as random logouts and it is genuinely hard to read from the logs.
the client side always feels like the missing half of these setups. you basically treat your portfolio like any other oauth provider, configure the client app with the endpoints your server exposes, authorize url, token url, userinfo if you got one. the docs for the plugin really just cover the server part and leave you guessing about the rest
Since you’re using it for authentication rather than delegated API access, make sure the provider is actually exposing OIDC, not just bare OAuth. And if you haven't already try and hit /.well-known/openid-configuration first and verify the issuer and the proper endpoints. Then check that the redirect matches Better Auth’s callback exactly.
Keycloak
If you write a really bad auth server and it will show that you don't really know what you were doing and still published it, that will be worse for portfolio than doing nothing