Single sign-on · Google Workspace

Google Workspace

Google Workspace works well, with one important difference from the other providers: it does not publish a metadata URL. That makes certificate renewal something you have to do deliberately, and it is the single most common way Google-based single sign-on breaks.

Read this before you rotate a certificate

Google gives you a downloadable XML file, not a URL we can keep reading. So when you create a new certificate in Google and switch your app to it, we will still be using the old one until you send us the new metadata. Sign-in breaks at the moment you switch, not when the old certificate expires.

Setting it up

The step-by-step walkthrough lives in the product, at Organisation settings → Single sign-on. Use it for the actual setup: it shows your live service provider values with copy buttons.

In outline, you will:

Create a custom SAML app in the Google Admin console.
Download the metadata XML file Google generates.
Paste our ACS URL and entity ID into the service provider details.
Leave attribute mapping alone — the default is what we need.
Turn the app on for the organisational units who should have access.
Upload the metadata file into Stable Baseline.

Certificates and rotation

	Google Workspace
Metadata	Downloadable XML file only — no URL
Certificate lifetime	5 years
Rotation style	You create a second certificate and switch the app to it
Do you need to do anything?	Yes, every time — this is the important one

Google’s own documentation is explicit about this: after assigning a new certificate to a SAML app you must also update the service provider, or sign-in with that app will fail. We are the service provider, and the only way to update us is to send the new metadata.

A five-year certificate is also one nobody has a reminder for, which is why we start warning you earlier for Google than for the other providers.

Renewing a certificate, safely

Do these in order. The order is what avoids an outage.

In the Google Admin console, go to Security → Authentication → SSO with third-party IdP and create a second certificate. Do not remove the first one yet.
Download the metadata file for the new certificate.
Upload it to Stable Baseline first, before switching anything in Google. Organisation settings → Single sign-on → update metadata.
Now switch your SAML app in Google to the new certificate.
Confirm someone can still sign in, then remove the old certificate in Google.

Why upload to us first

We accept the certificate from your metadata immediately, so uploading first means both certificates are trusted at the moment you switch. Doing it the other way round leaves a gap where Google is signing with a certificate we have never seen, and nobody can sign in.

What we will tell you

Because nothing here refreshes on its own, we start earlier for Google: emails to your owners and administrators at 90, 60, 30, 14, 7, 3 and 1 days before expiry, and daily once it has expired. The expiry date is also shown in your single sign-on settings.

Put it in a calendar too

Five years is long enough that people change roles. A shared calendar reminder a month before the expiry date, pointing at this page, is worth the two minutes it takes to create.

If sign-in has already broken

Upload the current metadata file from Google into Stable Baseline. That restores trust immediately. If you have enforcement switched on and cannot get in to do that, an organisation owner can still sign in with their password and two-factor authentication — that exemption exists for exactly this situation.

Single sign-on overview

Enforcement, the owner break-glass, and what happens on a downgrade.

Microsoft Entra ID

Set up SAML with Entra ID, formerly Azure AD.