Most frequent questions and answers about Google and Okta Provisioning and SSO Integration.
Okta intentionally does not delete users in Google, rather suspend them as you see here https://support.okta.com/help/s/article/Google-Apps-Deployment-Guide
I think it makes sense as deletion in Google is pretty sensitive, once you delete the account, you get 25 days to recover it, and if you miss it, your data is gone forever.
I have a script which you can leverage to unassign (or delete) users in bulk, you can access these scripts below-:
You should check for the following-:
- Have you configured “Network Masking”? If yes, make sure you use the IP address that is part of your IP range in Networking masking.
Also, make sure you are not testing through mail.google.com, but rather mail.google.com/a/yourdomain.com
- Google Super Admins by pass SSO, so make sure you are testing with a regular Google user, and not a super admin one.
- SAML SSO is not supported on POP/IMAP, so ensure you are testing with Google Web application.
You should ensure that your Okta SAML response include valid Google ACS URL which can either be-:
and in case if you are getting the error “It means the Recipient attribute in the SAML Response does not match the Assertion Consumer Service (ACS) URL.” that means though you SAML includes the recipient but not the correct one as provided above.
This error indicates issues with your certificate (e.g private key used to sign SAML does not match your public key certificate that you uploaded to Google Workspace).
Please upload the right certificate again that you downloaded from Okta to Google Workspace and try again.
No, once Okta authenticates your user to Google, then a session is established between the user and Google which Okta do not control.
So you should define your session control in Google, which should ideally be less than your session configured in Okta.
You can read my blog post here about session control in Google Workspace or GCP.
You can not, as Google does not support multiple identity providers.
Though it depends on your scenario, but you might be able to manage this scenario within your Identity provider (e.g Okta).
For e.g -: If you have two set of users (which are different because of their domain name, or any attribute), and you want them to be authenticated via different Identity providers (e.g abc.com users should be authenticated against Okta, and xyz.com users should be via Azure).
You can do following in this specific use case-:
1. Configure required Identity provider in Okta (e.g Azure in above example use case).
2. Configure Google as service provider (with Okta as identity provider).
3. Create an IdP discovery rule in Okta which says (i) if the user is trying to access Google application AND (ii) user domain name is xyz.com, then Azure is the identity provider.
Now, when your xyz.com users try to authenticate to Google, they’ll be redirected to Okta –> Azure –> Okta –> Google, some of this interaction will be invisible to the end user though.
Ask it in the comments below, and I would try to answer it (if i can) as soon as I get time.