Single Sign On

I'm speccing how to offer my users single sign on across multiple websites/apps. I wasn't sure if Elements could do this in some way out of the box. Astra says I should use Better Auth. Curious if you agree.

6

1 comment · 5 replies

@chris 2h ago edited

Do you mean something like OAuth for your own site, with Google, Github, etc as authentication providers? Or did you mean something else?

If the former, you definitely do NOT need a third party provider for that. The agent can wire oauth into an Elements site easily. Your agent should already be able to figure this out, but if it struggles let me know and we'll build a new recipe for it. It should modify the existing users table in your own database with the fields necessary to do the oauth dance with whatever providers you want to enable. The protocol is well known and the agents should already be able to do it.

If you want to connect single sign-on from your company using something like Okta, that should also be possible. These are all just protocol specs that an agent can learn very easily.

If I misunderstood, let me know and I'll give a better answer!

What I mean is, say someone subscribes to my newsletter for $ per month. Say that's at my custom blog/newsletter (beehiiv replacement) at justin.com (opens in a new tab). they can log into justin.com (opens in a new tab) to see their subscription info like they would on any app. But I also have another product, maybe even a different brand, over at justincommunity.com (opens in a new tab). I'd like my newsletter subscribers to just login to the community with the login they already have at justin.com (opens in a new tab)! Basically anything I ever create and sell in the justin universe, if you've ever signedup on justin.com (opens in a new tab) then you can just login anywhere else with the same credentials. My agent thinks I should use Better Auth to do this. What do you think?

Got it, thanks! You don't need a third-party auth library for this.

Make justin.com (opens in a new tab) the sign-in hub. It already has your users table and their subscriptions in your own database. When someone visits justincommunity.com (opens in a new tab), it sends them to justin.com (opens in a new tab) to sign in, and justin.com (opens in a new tab) sends them back signed in. If they're already signed in at justin.com (opens in a new tab), that happens without asking again. This is OpenID Connect, the standard sign-on protocol built on OAuth, and it's how "Sign in with Google" works. In this case, justin.com (opens in a new tab) plays Google's role for every site in the justin universe.

An AI agent can build both sides in Elements easily: the hub on justin.com (opens in a new tab), and the sign-in on each other app. Each app can also ask justin.com (opens in a new tab) what the person subscribes to, so the community can check for a paid newsletter subscription before letting someone in.

If your agent struggles with it, let me know and we'll build a new recipe for it!

OK cool! Will do

Turns out Better Auth is just a library not a paid service. I wonder how to think about libraries in general. With Elements, should you just tell the agents to not use libraries in general?

@justin (opens in a new tab) No, libraries are fine, just be picky about them. If Elements already does it, use that. Auth is the main case: Elements already has your users, sessions and database working together, so an auth library adds a second set of tables and sessions to keep in sync.

If it's a well documented HTTP protocol, like OpenID Connect or a webhook, have your agent build it. It's a few files of your own code that you can read and change, and agents are good at following a published spec.

If it's something sophisticated that would take your agent significant time to get right, like generating PDFs or processing images, consider a package. elements install takes any npm package and builds it like your own code.

Add a comment