Google SSO in SuiteCRM 8, and what it really takes

A client asked for three things inside SuiteCRM: sign in with Google, their email, and their calendar. The first one on its own is a common request with more than one ready-made answer. Making that one sign-in also grant access to their email and calendar, and set up calendar sync for everyone, is where the real work was.

This is a companion to my SuiteCRM migration case study, where single sign-on was one piece of a larger rebuild. That post told the project story. This one stays on the sign-in itself: when you do not need a build, why this one did, and the parts that decide whether it holds up in production.

First, check whether you need a build at all

If all you want is for people to log in with their company Google account, start with what already exists. SuiteCRM 8 has SAML sign-in built in, switched on in its configuration, and Google Workspace can act as the identity provider for it. The SuiteCRM Store also lists Google login add-ons. If you go that way, check that the one you pick supports your exact SuiteCRM version before you buy it.

This project needed more than sign-in. The client also wanted their email and calendar inside the CRM. For that, the CRM needs each person's permission to use their Google data, and every user needs a calendar connection set up. Asking every employee to set that up by hand was the thing to avoid, so the sign-in itself does it. That part is a build, and it is what the rest of this post is about.

The core of the job: one login, two sessions

Building your own sign-in route runs straight into how SuiteCRM 8 is put together. It is effectively two applications sharing one codebase: a modern layer built on Angular and the Symfony framework, and underneath it the long-standing legacy CRM engine that still runs most of the business logic. A login has to be recognised by both, from the same click, in the same request. They use different session mechanisms, so the sign-in quietly does the work twice and keeps them in step. Miss either one and the user is only half signed in.

Two details matter even at a high level. The session identifier is replaced at the moment of sign-in, which closes a common session-hijacking trick. And the sign-in only accepts accounts on the company's own Google domain: a personal Gmail address is turned away before any CRM account is created.

When a colleague signs in for the first time, their CRM user is created from their Google profile as a normal, non-admin user. Nobody has to create accounts in advance or send invitations. When someone leaves, suspending their Google account stops them signing in with Google. It is still worth deactivating their CRM user too, because Google is not the only way in while password login stays switched on.

The login flow, without the plumbing

SuiteCRM 8's login screen ships as a compiled frontend, so you cannot simply edit a button into it. Rebuilding that frontend from source for one button is a heavy commitment. The pragmatic answer is a small, self-contained script that adds a "Sign in with Google" button to the existing screen once it has loaded. There is nothing to maintain in a frontend build pipeline, and the button sits naturally on the page. The trade-off is that it hooks into SuiteCRM's own login page, so it is one of the things to check after every SuiteCRM upgrade.

From there it is the standard Google sign-in flow: the user is sent to Google, approves access, and comes back with a one-time code that the server exchanges for tokens behind the scenes. The user's password is only ever seen by Google.

What the CRM asks for is worth naming, because a Google Workspace admin sees exactly this on the consent screen and should ask you to justify it. This build requests the user's identity and email address, their Google Calendar and, because the client wanted email inside the CRM, access to their mailbox. That last one is a broad permission. It is there because the business asked for it, and it is exactly the scope a Workspace admin should question, so have a clear answer ready.

Calendar sync is where the care goes

Signing in is the visible half. The half that needs the most care is calendar sync. The promise to the user is simple: sign in once, and your Google Calendar shows up in the CRM without you configuring anything.

SuiteCRM 8.10 has a newer calendar sync framework, and SuiteCRM keeps Google tokens in more than one place. Only the newer framework's own connection records drive its sync job, so tokens saved where the older Google sync used to look are never seen by it. The first version of this build saved tokens the way the older sync expected. The final version gives each user their own encrypted Google connection, wired to the new sync job and refreshed every time they sign in.

For the user, a calendar account is created the first time they sign in, and its connection is refreshed every time they sign in again. For the business, "it just works" is something you build and verify, not something you assume.

The infrastructure detail that silently breaks OAuth

One more detail, because it stays invisible until it bites. Many production CRMs sit behind a reverse proxy that handles HTTPS, while the application itself receives plain internal traffic. Google is strict about the address it sends users back to after sign-in: it has to match an address registered for the app exactly, including the https.

Left unconfigured, the application does not know it is being served over HTTPS, builds an http address, and Google rejects the sign-in. It looks like a problem with the Google setup when the real cause is the proxy. The fix is a few lines of standard configuration that tell the application to trust the proxy's "this was HTTPS" signal. It is easy to lose time on if you do not know to look for it.

If you are evaluating SuiteCRM SSO

• Decide what you actually need. For sign-in only, look at SuiteCRM 8's built-in SAML sign-in or a Store add-on that supports your version. If sign-in should also grant Gmail and Calendar access and set up calendar sync for every user automatically, that is where a custom build like this one comes in, unless an add-on covers it for your version.
• The value is real. Company Google login, accounts created on first sign-in, company domain only, Gmail and Calendar access granted in the same step, and calendar sync that nobody has to configure.
• The risk is in the invisible parts. The second session, where the tokens live, the proxy signal. None of them show up in a quick demo, and all of them decide whether it holds up in production.
• Plan for upgrades. Anything that hooks into SuiteCRM's own screens, like the added sign-in button, needs a check after each upgrade. Keep the custom pieces few and in known places so that check is quick.

Google sign-in for SuiteCRM 8 is very achievable. When it is finished it is the least dramatic feature in the system: people click one button and they are in. Getting to undramatic is the work.

Quick answers

Does SuiteCRM support Google single sign-on?

Yes. SuiteCRM 8 includes SAML sign-in, which Google Workspace can act as the identity provider for, and the SuiteCRM Store lists Google login add-ons. If the same sign-in should also grant access to each person’s Gmail and Google Calendar and set up calendar sync, that is where a custom integration like the one described here comes in.

Do I need custom development for Google sign-in on SuiteCRM?

Not always. For sign-in alone, start with SuiteCRM 8’s built-in SAML sign-in or an add-on that supports your SuiteCRM version. Custom development makes sense when sign-in should also grant access to Gmail and Google Calendar and set up each user’s calendar sync automatically.

Will users’ calendars sync on their own?

They can. When the sign-in is wired into the calendar framework in SuiteCRM 8.10, a calendar account is created on first sign-in and its connection is refreshed at every sign-in after that, so users configure nothing.