AWS
Security
Tutorials
AWS IAM Identity Center with Google Workspace as an IdP: 2026 Setup Guide
TL;DR
AWS SSO was renamed to IAM Identity Center in July 2022, and the user provisioning story has changed since then. If you set this up before 2023, you were probably creating users manually in the console - there is now a SCIM 2.0 integration with Google Workspace that handles automatic user sync. This guide covers the full 2026 workflow: SAML setup, automatic provisioning with SCIM, group management (the part SCIM still does not handle), AWS CLI configuration, and the troubleshooting steps that come up most often.
Setting this up before 2023 meant creating every user manually. That was annoying but workable for small teams. The part that bit people was offboarding - a user gets suspended in Google Workspace, but their AWS access stays active until someone remembers to remove it. For most teams, that memory is unreliable.
AWS renamed the service in 2022, redesigned the console, and added SCIM-based automatic provisioning. The manual workflow still works, but it is now the slow path.
Here is where things stand in 2026:
The SAML connection itself has not changed much - it is still the same sequence of exchanging metadata between Google and AWS. What is different is everything that happens after authentication: how users get provisioned, how groups are managed, and how developers connect via CLI.
In this article:
What Is AWS IAM Identity Center? #
Terminology
AWS Single Sign-On (AWS SSO) was renamed to AWS IAM Identity Center in July 2022. The service is identical - same console path, same APIs, same feature set. Searching for "Single Sign-On" in the AWS console redirects to IAM Identity Center.
Identity Provider (IdP): the system that owns user identities and handles authentication. In this guide, that is Google Workspace.
SAML 2.0: the protocol that passes authentication assertions from Google to AWS, used for browser-based SSO login.
SCIM 2.0: a separate protocol for provisioning - automatically creating, updating, and deactivating user accounts across systems.
IAM Identity Center sits at the AWS Organization level, not the individual account level. You configure it once in the management account and it covers every account in your organization. Users sign in through a single access portal, see the accounts they have access to, and assume a role with one click. For a complete walkthrough of IAM Identity Center from scratch - covering all identity provider options and organizational setup - see our 2026 IAM Identity Center guide.
Connecting Google Workspace as the IdP makes sense if Google is already your corporate directory. Users are there from day one; when they leave, their Google account gets suspended. With IAM Identity Center wired to Google Workspace, that suspension cascades to AWS access automatically - no separate offboarding step, no stale credentials left behind.
One thing worth stating: IAM Identity Center is free. Google Workspace SCIM provisioning is included in your existing plan. There is no licensing cost for either side of this integration.
Prerequisites #
- An AWS Organization with IAM Identity Center not yet configured, accessed from the management account or a delegated admin account
- Google Workspace admin access to create a SAML app and configure provisioning
- AWS CLI v2 installed locally if you want to configure CLI access
- IAM Identity Center must be an organization instance for multi-account use - creating it in a standalone account outside AWS Organizations gives you an account instance with limited capability and no cross-account access
Setting Up the SAML Connection #
This part has not changed dramatically since the service launched. The console UI looks different, but the steps are the same sequence.
Step 1: Enable IAM Identity Center in AWS #
Sign into the AWS Management Console from the management account, search for IAM Identity Center, and click Enable. Once it starts, go to Settings > Change under the Identity source section, and choose External identity provider.
Scroll to Service provider metadata and click Show individual metadata values. Three values appear: the IAM Identity Center sign-in URL, the ACS URL, and the issuer URL. Keep this window open.
Step 2: Create the Google Workspace SAML App #
In Google Admin, go to Apps > Web and mobile apps > Add app > Add custom SAML app. Name it something clear -
AWS IAM Identity Center works.On the Google IdP information page, download the IdP metadata file (Option 1: Download IdP metadata).
Fill in the service provider details:
- ACS URL: the IAM Identity Center ACS URL
- Entity ID: the IAM Identity Center issuer URL
- Name ID format: EMAIL
- Name ID: Basic Information > Primary email
Skip attribute mapping and click Finish. Enable the app for everyone.
Step 3: Upload the Google Metadata to AWS #
Back in the IAM Identity Center console, upload the
GoogleIDPMetadata.xml file, click Next, type ACCEPT, and click Change identity source. The SAML connection is now active. Users can authenticate via Google Workspace, but need to be provisioned and assigned to accounts before they can access anything.Automatic User Provisioning with SCIM #
Before 2023, the only option was creating users one by one in the IAM Identity Center console, matching the email address exactly to their Google account. That still works. The problem is both sides of it: onboarding means creating users manually, and offboarding means remembering to remove them manually too.
SCIM 2.0 provisioning changes this. When a user is added to the Google Workspace app, they appear in IAM Identity Center automatically. When they leave and are suspended in Google, that change propagates to IAM Identity Center based on your deprovisioning policy.
Step 1: Enable Automatic Provisioning in AWS #
In IAM Identity Center, go to Settings > Automatic provisioning and click Enable. AWS generates a SCIM endpoint URL and a bearer token. Copy both - the token cannot be retrieved again once you close the dialog.
Step 2: Configure SCIM in Google Workspace #
In Google Admin, go back to your AWS SAML app. You should now see a Provisioning tab (it appears after the app is saved). Enter the SCIM endpoint URL and bearer token from AWS.
Map these attributes from Google to IAM Identity Center:
Mark
userName, givenName, and familyName as required. Save the configuration and run a test sync.SCIM will silently reject users with incomplete profiles. If a user in Google Workspace is missing a first name, last name, or display name - or has multiple values for a single attribute (two work phone numbers, for example) - SCIM rejects them with error
45003. Before enabling provisioning, run a completeness report in Google Admin to find users with missing directory data.Provisioning typically completes within a few minutes. AWS documentation says up to 24 hours, but in practice it is much faster. For official AWS guidance on this configuration, see the IAM Identity Center Google Workspace setup guide.
Deprovisioning Behavior #
When a user is removed from the Google Workspace app or suspended in Google Admin, what happens to their IAM Identity Center account depends on your deprovisioning policy, configured in Google Admin's provisioning settings. The options are: suspend immediately, suspend after a delay, or delete. Suspending immediately is the safer default - it removes AWS access as soon as the Google account is suspended, without waiting for a manual cleanup step.
SOC 2 and ISO 27001 both require demonstrating that departed employees lose access in a timely, auditable way. Automatic deprovisioning through SCIM gives you that story; manual deprovisioning does not. If you want automated evidence rather than manual exports, CloudQuery Policies let you run access review queries on a schedule and surface violations without someone remembering to check.
Groups: The Part SCIM Still Does Not Handle #
SCIM syncs users. It does not sync groups. Google Workspace's SCIM implementation handles user lifecycle events, but groups defined in Google do not come over as IAM Identity Center groups. This is a real limitation for any organization that wants group-based permission set assignments - and most organizations with more than a handful of developers do.
You have two realistic options here.
Create groups manually in IAM Identity Center. Go to Groups, create the groups you need (Engineering, Platform, Finance, whatever makes sense for your structure), then add users from your SCIM-provisioned list. More upfront work, no additional tooling, and the groups are static until you update them.
Use ssosync. The awslabs/ssosync project syncs both users and Google Workspace groups to IAM Identity Center. It runs as an AWS Lambda function on a schedule (every 15 minutes by default) and uses the Google Admin SDK alongside the IAM Identity Center API to keep groups in sync. The project is actively maintained as of 2025 and handles deprovisioning correctly.
For teams under 30 people, SCIM plus manual groups is probably fine. For larger organizations with frequent team changes, ssosync is worth the setup time. The project's README covers the setup (Google Service Account, IAM role, group mapping) in detail.
Permission Sets and Multi-Account Access #
Permission sets define what a user can do when they assume a role in an account. Create them before assigning users or groups.
In IAM Identity Center, go to Permission sets and create at least two to start: one for read-only access and one for your developers. A few things worth getting right from the start:
- Do not assign
AdministratorAccessbroadly.PowerUserAccessgives full build capability without the ability to modify IAM - that is the right default for most engineers. ReserveAdministratorAccessfor actual platform admins who genuinely need it. - Set session duration explicitly. The default is 1 hour, which is fine for console work. For developers using the CLI throughout the day, 8 to 12 hours reduces the friction of re-authenticating mid-workday.
- Create multiple permission sets.
DeveloperAccess,ReadOnlyAccess,FinanceReadOnly- assign the right one per team per account rather than one catch-all.
After creating permission sets, go to AWS accounts in IAM Identity Center, select an account, click Assign users or groups, and attach the user or group to the appropriate permission set. Repeat for each account.
Once you have more than a few permission sets across multiple accounts, it gets hard to keep track of which ones have
AdministratorAccess attached. CloudQuery can surface this across your entire organization with a single query:-- Find permission sets with AdministratorAccess attached
-- Verify table names against your CloudQuery schema
SELECT
ps.name AS permission_set_name,
ps.arn,
mp.managed_policy_arn
FROM aws_ssoadmin_permission_sets ps
JOIN aws_ssoadmin_permission_set_managed_policies mp
ON ps.arn = mp.permission_set_arn
WHERE mp.managed_policy_arn = 'arn:aws:iam::aws:policy/AdministratorAccess'
ORDER BY ps.name;
It is also worth knowing that IAM Identity Center has specific privilege escalation vectors - if an attacker or misconfigured user gains access to certain Identity Center APIs, they can escalate beyond their intended permission set. See this deep dive on Identity Center privilege escalation and hardening for what to watch for before you finalize your setup.
Configuring AWS CLI for SSO Access #
AWS CLI v2 has built-in SSO support. The current workflow uses
aws configure sso rather than manually editing files:aws configure sso
This prompts for the SSO start URL (found in IAM Identity Center under Settings > AWS access portal URL), the IAM Identity Center region, and then walks through selecting an account and permission set. It writes the result to
~/.aws/config.The resulting configuration looks like this:
[profile my-account-dev]
sso_session = my-org
sso_account_id = 123456789012
sso_role_name = DeveloperAccess
region = us-east-1
output = json
[sso-session my-org]
sso_start_url = https://your-org.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access
The
sso-session block is shared across multiple profiles - if you have five accounts, each gets its own [profile ...] block but they all reference the same [sso-session my-org]. You authenticate once per session.aws sso login --profile my-account-dev
aws sts get-caller-identity --profile my-account-dev
The first command opens a browser for Google authentication. After that, standard CLI commands work with
--profile my-account-dev. See our AWS CLI SSO setup guide for more detail.Testing Your Setup #
Once everything is configured, walk through the end-to-end flow:
- Sign into Google Workspace as a test user who has been provisioned and assigned to an account.
- Open the Google apps launcher (the grid icon in Gmail or Google Drive).
- The AWS IAM Identity Center app should appear. Click it.
- You should land on the AWS access portal showing the accounts and permission sets assigned to that user.
- Click into an account to open the AWS console, or copy temporary credentials for CLI use.
If the app does not appear in the launcher, check that the Google SAML app is enabled for the user's organizational unit. If it appears but the AWS access portal shows no accounts, verify the user has been assigned to at least one account with a permission set in IAM Identity Center.
Troubleshooting Common Issues #
SCIM Error 45003: User Provisioning Fails Silently #
This is the one that trips up most teams during initial rollout. The symptom is confusing: users exist in Google Workspace, provisioning ran without errors, but they never appear in IAM Identity Center. The cause is almost always incomplete profile data. SCIM requires first name, last name, display name, and a primary email. It also rejects users with multiple values for a single-valued attribute - two work phone numbers on a user record, for example.
Fix the profile in Google Admin and trigger a manual sync by editing any field on the affected user's record. Google does not automatically retry failed syncs.
"You Do Not Have Any Accounts" on the AWS Access Portal #
The user authenticated via SAML successfully - the Google side is working. The problem is that no account assignment exists yet. Go to AWS accounts in IAM Identity Center and verify the user or their group has been assigned to at least one account with a permission set attached. SAML only handles authentication; account access is configured separately.
SAML Assertion Fails on Login #
Usually a NameID mismatch. The email in the SAML assertion from Google does not match the username of any existing user in IAM Identity Center. If using SCIM, confirm the user provisioned successfully before testing login - run through the SCIM error 45003 checklist first. If managing users manually, the user must exist in IAM Identity Center with the exact primary Google email as their username, no trailing spaces, no aliases.
MFA Is Not Prompting #
This is expected behavior. When Google Workspace is the IdP, Google handles MFA entirely. IAM Identity Center trusts the authenticated session from Google and does not layer a second factor on top. Configure your MFA requirements in Google Workspace - hardware keys, Google Authenticator, and Titan keys all work. IAM Identity Center's built-in MFA settings only apply when using the AWS-managed directory, not an external IdP like Google Workspace.
Accidentally Deleted the DO_NOT_DELETE Identity Provider #
When you connect an external IdP, IAM Identity Center creates an IAM identity provider named
AWSSSO_xxxxxxxxx_DO_NOT_DELETE in each account. Deleting it breaks SSO login for that account. If this happens, see the recovery guide for restoring AWS SSO after deleting the identity provider.How Do You Audit IAM Identity Center Access Over Time? #
After setup, you will want to periodically verify that permission set assignments are correct and that deprovisioned users do not have stale access. Clicking through the console account-by-account does not scale once you have more than a handful of accounts.
The CloudQuery AWS Source integration syncs IAM Identity Center data to SQL, including the
aws_identitystore_users, aws_ssoadmin_permission_sets, and aws_ssoadmin_account_assignments tables. That lets you query across your entire organization from one place:-- Find all users and their account assignments
-- Verify column names against your CloudQuery schema
SELECT u.user_name, a.account_id, a.permission_set_arn
FROM aws_identitystore_users u
JOIN aws_ssoadmin_account_assignments a
ON u.user_id = a.principal_id
ORDER BY u.user_name;
That query is good for access reviews and compliance audits, where you need to show what each person can access across all accounts - without clicking through each one manually.
SCIM handles user lifecycle, but account assignments are managed separately. When someone is suspended via SCIM, their Identity Center user account gets suspended - but any existing account assignments are not automatically removed. This query finds those cases:
-- Find suspended users who still have active account assignments
-- Verify column names against your CloudQuery schema
SELECT u.user_name, a.account_id, a.permission_set_arn
FROM aws_identitystore_users u
JOIN aws_ssoadmin_account_assignments a
ON u.user_id = a.principal_id
WHERE u.status = 'Suspended'
ORDER BY u.user_name;
A suspended user cannot authenticate, so this is not an active security gap - but it is noise in your access inventory and will show up in compliance reviews. Cleaning these up keeps your assignment data accurate. For broader AWS security posture monitoring beyond just IAM Identity Center, see CloudQuery's security solutions. For deeper IAM auditing patterns across users, roles, and access keys organization-wide, see continuous AWS IAM security best practices.
Key Takeaways #
- IAM Identity Center (renamed from AWS SSO in July 2022) is free and manages access across all accounts in an AWS Organization
- SCIM 2.0 is now the standard approach for user provisioning - it handles create, update, and deprovisioning automatically from Google Workspace
- SCIM does not sync groups - use manual group creation in IAM Identity Center or the ssosync Lambda for group-based access control
- Create permission sets per job function with appropriate session durations; avoid broad
AdministratorAccessassignments aws configure ssois the current CLI workflow; thesso-sessionblock in~/.aws/configis shared across multiple account profiles so you authenticate once- SCIM failures are almost always caused by incomplete user profiles in Google Workspace (missing first name, last name, or display name)
- MFA is handled by Google Workspace when using an external IdP; configure it there, not in IAM Identity Center
Audit Your IAM Identity Center Configuration
CloudQuery syncs IAM Identity Center users, permission sets, and account assignments to SQL for access reviews and compliance auditing. Query across your entire AWS organization to catch stale permissions and verify deprovisioning worked as expected.
Frequently Asked Questions #
What Is the Difference Between AWS SSO and IAM Identity Center? #
The same service, renamed. AWS rebranded AWS Single Sign-On as AWS IAM Identity Center in July 2022. Same APIs, same console path, same feature set.
Does Google Workspace Support Automatic User Provisioning to AWS? #
Yes. Enable automatic provisioning in IAM Identity Center to get a SCIM endpoint and bearer token, enter them in Google Admin's provisioning settings, and users sync automatically from that point forward.
Can I Sync Google Workspace Groups to IAM Identity Center? #
Not with native SCIM - it only handles user lifecycle. For group sync, use awslabs/ssosync, which runs as an AWS Lambda and syncs both users and groups from Google Workspace to IAM Identity Center.
How Long Does SCIM Provisioning Take? #
Usually a few minutes. AWS documentation says up to 24 hours, but initial provisioning completes much faster in practice.
How Do I Configure AWS CLI to Use IAM Identity Center? #
Run
aws configure sso, enter your SSO start URL and region, select an account and permission set. This writes an SSO profile to ~/.aws/config. Authenticate with aws sso login --profile <profile-name> before running commands.What Happens When I Remove a User from Google Workspace? #
With SCIM configured, the user's IAM Identity Center account is suspended or deleted based on your deprovisioning policy in Google Admin. Without SCIM, nothing happens automatically.
Why Is SCIM Rejecting Some of My Users? #
Incomplete user profiles. SCIM requires first name, last name, display name, and username. It also rejects users with multiple values for a single attribute (two work phone numbers, for example). Run a completeness report in Google Admin to find affected users.
Do I Need ssosync If I Have SCIM Set Up? #
Only for group-based access control. SCIM handles user lifecycle. ssosync adds group sync on top. If you assign users directly to accounts without using groups, SCIM is sufficient.
