Google Workspace

Read the two consequences before you start

Google Workspace has two properties that are not configuration choices and cannot be worked around. Both are covered below. If you plan your role assignment around groups, you will need to change the plan.

Setup

1. Create an OAuth client.

   Google Cloud console → APIs & Services → Credentials → Create credentials → OAuth 2.0 Client ID, type Web application. Set the authorised redirect URI to the portal’s origin.

2. Register the provider in Seylo.

   Single sign-on → Add provider → preset Google Workspace. The discovery URL is fixed at https://accounts.google.com/.well-known/openid-configuration.

3. Set the audience to the OAuth client ID — the value ending .apps.googleusercontent.com.

4. Set hd — this is required.

   The discriminator claim is hd and the value is your Workspace primary domain, for example acme.example. The registration is refused without it.

   Why: every Google Workspace on earth shares the issuer https://accounts.google.com. Without hd your organisation could not be told apart from any other Google customer, and a token signed for them would be signed for you.

5. Set base roles, because step 6 explains why claim mapping cannot work.

6. Run test login.

Consequence 1 — no groups, ever

A Google ID token carries no group and no role information, and there is no configuration that adds it. Groups are readable only from the Admin SDK Directory API, using a service account with domain-wide delegation — a different trust model entirely, and not part of a login.

So role assignment works differently here:

• Set base roles to give every member of the Workspace a floor. viewer is the usual choice.
• Grant anything above that under explicit user roles, per person.

This is not a Seylo limitation you can configure around; it is what the token contains. See managing users.

Consequence 2 — personal Gmail accounts cannot sign in

A personal @gmail.com account carries no hd claim, so it is rejected with discriminator-absent.

That is the intended outcome. If someone reports “I can’t sign in with Google”, the first question is which account they used.

Common problems

Symptom	Cause	Fix
discriminator-absent	Signed in with a personal Gmail account	Use a Workspace account
discriminator-unmatched	Signed in from a different Workspace domain	Check the hd in the test-login report against the registered value. Comparison is case-insensitive and trimmed, so case is never the cause
Everyone has no permissions	Base roles not set, and Google sends no groups	Set base roles to viewer
Registration refused	No hd value supplied	hd is mandatory for the Google preset

Secondary domains

hd carries the domain of the signed-in user. If your Workspace has secondary domains and people sign in under them, each domain that people actually use needs its own registration — one (issuer, hd) pair per domain.