Google Cloud console SSO.
No Google accounts.
Workforce Identity Federation lets your users open the Google Cloud console and gcloud CLI with their Monosign identity, local or synced from Active Directory. No user is created on the Google side: every sign-in maps to a workforce principal, and IAM roles attach to your Monosign groups.
- OIDC · authorization code + PKCE
- Console + gcloud CLI
- Verified end to end
From OIDC key to console session.
Five steps on two consoles. Group-based IAM from day one.
- 01
Create the application and OIDC key in Monosign
Add a Web application (URL: the Google Cloud console) and create an OIDC/OpenID key on it. The Client Id and Client Secret go to Google in step 3. Set the signature algorithm to RS256 and the scope list to openid email profile.
Tip — Pin the global JWT issuer and configure an organization signing certificate first: Google validates tokens against your JWKS, and an ephemeral key would break the federation on every restart. - 02
Make the subject stable and map groups
Set the key’s Subject (sub) Format to the stable Monosign User Id (or add a Claim Mapping row sub → {{UserId}} on earlier versions), and enable Group Mapping with the attribute name "groups". Google builds the workforce principal from sub; a username-based subject would orphan all IAM grants the day a user is renamed.
Tip — Google requires the sub in the userinfo response to equal the sub in the ID token; the stable-Id configuration satisfies both, and the sign-in fails with a clear error when it is missing. - 03
Create the workforce pool and OIDC provider in Google Cloud
With the organisation-level workforce pool admin role, create a workforce pool and an OIDC provider pointing at your Monosign issuer, with the Client Id/Secret, response type "code", and an attribute mapping that carries google.subject, google.groups, and your email/username attributes.
Tip — Workforce pools are organisation resources: a project role is not enough, and a freshly granted org role can take a few minutes to propagate. - 04
Grant IAM roles to Monosign groups
Bind roles to principalSet://…/group/<Monosign group name> rather than to individual users. Membership then lives in Monosign: a user removed from the group loses the role at their next sign-in. An attribute condition on the provider can additionally restrict who may enter the pool at all.
- 05
Test the console and the CLI
Open the pool’s sign-in URL: Google redirects to Monosign, your policy runs, and the user lands in the console. For the CLI, generate a login-config file once (it contains no secrets) and have users run gcloud auth login with it.
Tip — Keep the pool session duration short, around an hour. Google holds its session for that long even after the Monosign session ends.
The complete walkthrough — with every screenshot, every flag, and version-specific notes — lives in our help center.
Ready to start managing
identities the right way?
Spin up a fully-loaded trial tenant in under five minutes. No credit card. No sales gate.