Best Way to Add Google Sign-In + Roles in Payload CMS?

kento105 months ago

15

• 

  doubtfulshark5 months ago

  I’m using clerk right now do to its simplicity. Payload has auth but I wanted to use an external service to manage authentication so I could focus on the actual development. I route users to a sign up page, that page has clerks provided component. Sign up creates the user in clerk. Clerk then emits several webhook events you can listen to in your Payload CMS backend. Store the clerkUserId, email, and what ever information you need from the payload in your users table. Clerk also has hooks you can use on the client to restrict access to certain pages. Clerk supports many oauth providers including Google.

• 

  kento105 months ago

  Thanks a lot for sharing your setup 🙌

  
  

  Clerk does look very clean and convenient, especially with webhooks + OAuth handled out of the box - so that’s a great suggestion👍

  
  
  

  That said, I’m currently looking for alternatives without a pay-per-user pricing model, since auth can become a major cost at scale.

  
  
  

  I’ve been looking into options like:

  
  

  - Payload OAuth2 Plugin

  
  

  - payload-auth

  
  

  - or even rolling it myself using something like Better Auth

  
  
  

  Because Payload evolves pretty fast, I wanted to sanity-check whether any of these approaches are considered “wrong” or risky long-term - auth is obviously one of the most critical parts of the system.

  
  
  

  From what I’ve read, Better Auth should work fine with Payload, but I’m currently wrestling with a few integration errors 😅

  
  

  So I’m mostly trying to figure out what people consider the most future-proof / maintainable approach today if you want Google OAuth + role-based access + subscriptions, but without managed auth pricing.

  
  
  

  If anyone has experience running OAuth “closer to Payload” (or lessons learned / gotchas), I’d love to hear it 🙏

• 

  rubixvi5 months ago

  https://rubixstudios.com.au/insights/payloadcms-custom-auth-strategy
  
  

  or you can implement your own auth for your own requirements

• 

  kento105 months ago

  Thanks a lot for sharing this - really appreciate it.

  
  

  I’ll definitely take a proper look at the article.

  
  
  

  This gives me a good direction, so I’ll close the thread.

• 

  __rik__5 months ago

  I'm using payload-auth-plugin. I'm doing the recommended thing of using separate collections for the admin GUI and other places (the hosted websites). The way you end up with it working is that you have an "Accounts" collection as well as the "Users" collection. The users collection has the email associated with the account as the login name. Throw your roles in there, too. The "Account" collection is the data from the external authn providers. You handle the authz in the Users table.. and also other tables, if you want to have a full setup.

  
  
  

  Now, that's just my experience having not done this much, so other people's advice should also be read.

• 

  kento105 months ago

  Thanks for sharing your experience - that setup with separate Users / Accounts collections makes a lot of sense 👍

  
  
  

  I was also considering payload-auth-plugin, but I got a bit cautious seeing no new commits for ~5 months and a few open issues. That said, it’s still really helpful to hear that it’s working well in practice.

  
  
  

  In the end, I decided to go with Better Auth as my auth strategy, mainly because of the ecosystem and plugins (e.g. Stripe integration).

  
  

  I’m still figuring out whether it makes more sense to use Payload’s native Stripe plugin or Better Auth’s Stripe integration - but that’s probably a topic for a separate thread 😄

  
  
  

  Overall, it’s actually nice to see that there are multiple viable ways to handle Google OAuth with Payload today.

  
  

  Hopefully, at some point we’ll get something more out-of-the-box in Payload itself - multiple auth strategies without having to wire everything manually or rely heavily on third-party plugins.

  
  
  

  Thanks again for the insight 🙏

• 

  __rik__5 months ago

  So, the back-story for me is that I started on using Payload for my personal project more than a year ago payload-auth-plugin was the choice I made then, and the dev was and is still active here. He appears to have a backlog because of some real-life stuff, but the core functionality does work, and currently works well enough for my admittedly small project.

  
  
  

  I can't speak to Stripe plugins, at all, except that I know it can be a mess, because of some of Theo's video. But then, they're also Theo videos...

• 

  kento105 months ago

  Nice backstory 🙂

  
  

  If the project is public, I’d honestly love to take a look - totally understand if it’s not though.

  
  
  

  And yeah… Stripe.

  
  

  That’s probably the part I’m the most cautious about right now. Auth feels manageable, but once subscriptions, webhooks and edge cases come in, it gets real very fast.

• 

  __rik__5 months ago

  You know how some people what to know how things work, so they take thme apart and look at the insides? I'm like that but I build them. I took a 20 yer break from web dev. The last website I made I made with PHP, a little CSS, and no Javascript at all, because it didn't work between browsers.

  
  
  

  during the pandemic, Theo popped up on YouTube for me, and I started watching about typescript, and I decided it's time ot remake my website.

  
  
  

  Got myself a Vercel account, a database with Neon, or someone similar, and started with Payload.

  
  
  

  Once I learned a lot, I threw it all away and started over.

  
  
  

  Then I lerned some more, threw it all away, and started over.

  
  
  

  Lerned some more, threw it all away and started over.

  
  
  

  Got sick, stopped for several months.

  
  
  

  Threw away what I had and started over because by then I'd actually delivered a Next.js project at work and understand a lot of things better, now.

  
  
  

  And that brings us to today.

  
  
  

  Today's task is to make a ContentBlock, which is a block that houses... blocks. And then ... figure out how to have Storybook show that I haven't broken it. Which is sort of like testing, but only testing a bit.

  
  
  

  Actually, I need to check the sensibility of my plan with people in

  #967097582721572937

  , because there's rpobably a better way to achieve what I'm trying to do.

• 

  kento105 months ago

  Haha, yeah - reading this felt very familiar 😄

  
  

  Looks like I’m not the only one who built something in Payload, dropped it, came back, threw it away… and repeated that cycle a few times.

  
  
  

  I actually planned to properly get into Payload for almost a year, lmao.

  
  

  Only once I really understood the config, collections and how everything fits together, something finally clicked.

  
  
  

  I used to be pretty critical of WordPress, but now it honestly feels like a nightmare.

  
  

  Once you get used to something as code-friendly and explicit as Payload, it’s really hard to go back.

  
  
  

  Good luck with your project 👌

• 

  __rik__5 months ago

  Oh I didn't

  plan

  to get in to Payload. I actually found Sanity first, and then realized that I didn't control my data, after I had done their intro course, which I still recommend because of the ideas in it.

  
  
  

  I'm not sure how I came across Payload - it might have been a recommendation on reddit or discord.

• 

  siebe.b5 months ago

  You dodged yourself a bullet haha

• 

  doubtfulshark5 months ago

  You can also check out the payload-auth plugin that uses better-auth. I think it was mentioned above but here is a link.

  https://www.payloadauth.com/

  , could be a viable solution. I wouldn’t worry about costs for an authentication service though. If you hit the user limit and go over that’s not a bad problem to have, unless you are working on a free to use app. Here is the link for better auth plugin

  https://www.payloadauth.com/
• 

  __rik__5 months ago

  I've looked at that, and I'm suspicious, because the "docs" are better-auth's docs. They don't have anything about the plugin...

• 

  kento105 months ago

  Thanks for the recommendation. Yeah, the lack of plugin-specific docs worried me a bit as well - it’s basically just Better Auth docs.

  
  
  

  In the end, I decided to go with a setup where Better Auth simply coexists alongside Payload CMS instead of relying on the plugin abstraction. I matched the Payload collections to what Better Auth expects (with a few adjustments), and this approach gives me nice control and transparency.

  
  
  

  For anyone interested, this repo was a really helpful reference:

  
  https://github.com/ElysMaldov/payload-better_auth-example