Most frequent questions and answers about Google and Okta Provisioning and SSO Integration.

WHY CAN'T WE DELETE GOOGLE USERS FROM OKTA?

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-:

1. Auto unassign Google Workspace licenses
2. Delete Google Workspace users in bulk with Ok Goldy

You should not delete your Google users or unassign their Google Workspace licenses unless you know what you are doing, you should ideally unassign their Google Workspace Business or Enterprise license and assign Google Workspace Archive User License so you pay less than regular Google Workspace license cost but still retain Google Workspace users’ data.

‍

WE HAVE CONFIGURED SSO BUT GOOGLE USERS CAN NOT REDIRECTED TO OKTA

You should check for the following-:

1. 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
2. Google Super Admins by pass SSO, so make sure you are testing with a regular Google user, and not a super admin one.
3. SAML SSO is not supported on POP/IMAP, so ensure you are testing with Google Web application.

‍

THIS SERVICE CANNOT BE ACCESSED BECAUSE YOUR LOGIN REQUEST CONTAINED NO RECIPIENT INFORMATION"?

You should ensure that your Okta SAML response include valid Google ACS URL which can either be-:

https://www.google.com/a/yourdomain.com/acs

or

https://accounts.google.com/a/yourdomain.com/acs

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.

‍

WHAT DOES THIS ERROR MESSAGE MEAN: "THIS ACCOUNT CANNOT BE ACCESSED BECAUSE THE LOGIN CREDENTIALS COULD NOT BE VERIFIED?

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.

‍

IF OUR USER LOGS OUT FROM OKTA, DOES HE GET LOGOUT FROM GOOGLE AS WELL?

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.

‍

HOW CAN WE SETUP MULTIPLE IDENTITY PROVIDERS IN GOOGLE?

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.