FAQ
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-:
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.
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.
19 thoughts on “Definitive Guide to Okta & Google Integration”
Hi Goldy,
We configured google and okta per Google documentation “BeyondCorp and Okta as Identity Provider” that very identical to your suggested configuration. Everything works as defined if user is logged into google. However, if it is not, the user experience looping when it goes to Okta login authentication, picking up MFA, getting google into login where it asks for username and then getting redirected back into Okta login.
Below are the user log snippets for both behaviors (user already logged into Google and have successfully logged into Okta vs. can not log into Okta, looping not been able to get in):
Please let me know your thoughts.
Thank you!
User Log snippet for Google Logged in before Okta authenticates, Okta authentication and User dashboard is provided as expected:
ztna tester (User)
User single sign on to app
SUCCESS
Salesforce.com (AppInstance)
ztna tester (AppUser)
Jun 15 11:58:32
ztna tester (User)
Evaluation of sign-on policy
ALLOW
BCE test rule for OktaIdP_BCEExample_Factor (PolicyRule)
Salesforce.com (AppInstance)
Jun 15 11:58:27
Okta Dashboard (PublicClientApp)
OIDC access token is granted
SUCCESS
(User)
Access Token (access_token)
Jun 15 11:58:27
ztna tester (User)
User single sign on to app
SUCCESS
Okta Dashboard (AppInstance)
ztna tester (AppUser)
Jun 15 11:58:27
Okta Dashboard (PublicClientApp)
OIDC id token is granted
SUCCESS
(User)
ID Token (id_token)
Jun 15 11:58:27
Okta Dashboard (PublicClientApp)
OIDC authorization code request
SUCCESS
(User)
Authorization Code (code)
Jun 15 11:58:27
ztna tester (User)
Evaluation of sign-on policy
ALLOW
BCE_Example_Test Rule (PolicyRule)
Okta Dashboard (AppInstance)
User Log snippet for user not logged into Google before logging into Okta and it logon process is looping as described above:
ztna tester (User)
Authentication of user via MFA
SUCCESS
ztna tester (User)
ztna tester (User)
Evaluation of sign-on policy
CHALLENGE
default (PolicyEntity)
default (PolicyRule)
Hi Goldy,
We are seeing some strange behavior with regards to the process of changing users’ licenses in AD and having it pull/push into Okta and then to Google Workspace. When doing so, the users get stuck marked “Suspended by Admin” and must be manually reinstated. This ties to a specific failover account that isn’t used, but I believe may be tied to the Okta/Google Workspace automation in some way. This did not used to happen, so I want to figure out what is this account’s role in our infrastructure and how to correct the workflow around changing licenses.
any insight as to why this is happening.
Thanks a lot in advance.
I think it is more towards Google’s abuse detection (sometime false positives too:), i would recommend you to contact Google support for it.
Hello Goldy,
If we have multiple domains and/or multiple OUs within our Google Workspace, can we enable Okta SSO/Provisioning for only a single domain or OU instead of the entire Workspace?
I ask this because we have service accounts and client accounts within our Workspace that we would not want to block access by configuring Okta to Google since they are not located within Okta.
Hi Goldy! Thank you for putting together this detailed guide!
I’ve followed your instructions on integrating Google Workspace in Okta so that user provisioning is managed from Okta. When I create a test user in Okta, the user is created in Google Workspace but it is immediately suspended. This creation process triggers a “Google Identity” alert and it in response, the new user is suspended. The only way to un-suspend the user is to login as that user and reactivate the account via SMS. I reached out to Google’s customer support and he told me this is the expected behavior when a 3rd party invokes a user creation call in Google Workspace.
Is this the same behavior you are experiencing? If so, is there a way to work around this?
Thanks!
It has nothing to do with your setup, it is usually around Google’s abuse protection, raise a ticket with Google support, and they should be able to help you.
Hi Goldy! Thanks for putting this resource together. It’s a real lifesaver!
I’m curious if you’ve ever experienced this issue, or have any thoughts as to what may be the problem:
A team I’m working with is testing Google Workspace Context-Aware Access levels with their core IT – despite meeting all of the CAA conditions, 1 of the 4 core IT users is denied access to Google Apps when navigating from OKTA. If they refresh, they are eventually granted access (though it can take anywhere from 10 seconds to10 minutes of refreshing). They can access Google Apps directly through the app URL with CAA levels applied, and can access Google Apps through OKTA when CAA levels are deleted – but not through OKTA when even a single CAA level is applied.
We’ve tried reconfiguring the CAA levels, attempted to login using different approved devices (mobile, desktop, chromebook), and ensured that the endpoint mgt extension is installed and synced, but this same issue still persists for this one user.
Do you have any insight as to what may be the issue between OKTA and Workspace in this instance, and how to resolve this issue?
Looking forward to hearing your thoughts. Thanks Goldy!
let me reach out to you personally to talk about this 1:1.
Hi Ben,
We experience the same thing and can’t seem to find the right solution. Okta support points to Google and vice versa.
On Chromebooks there is no problem but all out Mac / Windows users experience the exact same thing as you are describing. It looks like Endpoint Verification is too slow picking up the redirecting url or so.
We can’t find any documentation anywhere so it would be much appreciated if you or anybody else can help.
Looking forward to hearing from you.
Koen.
Hi Goldy,
Amazing guide and much appreciate you took to create this.
Questions
1. The “IP” range option, we will only need to provide the IP range or address for testing purposes correct? Let’s say I’m working from home and I use my home IP Address, I should be the only user that will be forced to authenticate through Okta when I setup GSuite/Okta integrations.
2. What happen to users who are using MS Outlook for example? Or they want to setup their Gmail on their phones?
3. We are currently a GSuite customer and we have 2 steps verifications enforced. How does this work?
Thank you very much!
Hi Michael, answers below-:
1. Thats right, if you put your home IP in network mask, then you would be redirected to Okta only if you try to login from this IP address, rest of the requests will take google as identity provider.
2. It depends on the MS Outlook version as it should support modern authentication to make it work with SAML SSO, you can get more information about it on this article by Microsoft https://docs.microsoft.com/en-us/office/dev/add-ins/outlook/authenticate-a-user-with-an-sso-token
Gmail mobile app works well with SSO, so when your users try to configure it, it will redirect them to your identity provider (e.g Okta).
3. Google’s two step verification will be ignored once you setup and enable third party identity provider (e.g Okta), however Google provides a feature called “Post SSO verification”, if you enable it, then Google would challenge the user for Google 2SV if it finds the login attempt as suspicious, more info about this feature is here https://support.google.com/a/answer/6002699?hl=en
hope it helps.
Hello Goldy,
we have setup Gsuite with Okta long time ago and it’s working fine. Now we tried to setup GCP with Okta and problem we are facing is:
This account cannot be accessed because the login credentials could not be verified.
I was listing certificate from Gsuite and GCP and found out they are not the same. If I create multiple GCP apps on Okta they all use the same certificate from first GCP app. I managed to get the same certs after I deleted all GCP apps and newly one used same cert as GSuite apps.
We have scenario where companies merged and initial domain that was primary before still is primary but all users are using new domain to log to Okta and GApps. For some reason Gapps work fine, but GCP is giving issues with credentials validation.
I tried implementing string replace on the domain so user matches primary domain (which is not his username, only email alias) but still same problem. Any thoughts on the problem?
Hi Damir – I am sorry, I could not understand it well enough.
there is just one connection between Okta and given Google tenant for sso (regardless of whether you use Google Workspace or also use GCP), so no multiple certs.
have you watched the video above?
if you have multiple Cloud Identity tenants, then you would do one connection per tenant in Okta OR use attribute transformation via okta expressions if it helps with your use case.
Hi Goldy,
Thank you so much for these guides!! It is a lot of work on your part..so sincerely THANK YOU!
I have a couple questions…
1. What do you recommend setting up first…GSuite SSO or GSuite Provisioning?
2. We have service email accounts, meaning, GSuite email accounts used to integrate applications, say, Zendesk integration with Jira…so we have a service account for that purpose…What will it happens to those accounts when SSO is turned on? How these accounts whould be handle when we turn OKTA SSO?
3. Okta already has user accounts information, when turning on GSuite provisioning… will these accounts duplicate in GSuite? If so, how to prevent these? Ideally would be …If Okta user already exists in GSuite, then do not create…if user doesn’t exist… create account.
Thank you in advance for your guidance..
Your welcome, comments below-:
1. If you are you going to leverage Okta for both provisioning and SSO, then ideally you should setup provisioning first.
2. If the associated applications (e.g Zendesk et) are leveraging OAuth tokens (taken via associated Google Workspace user consent), then these applications should not be impacted, as they’ll keep directly calling Google’s OAuth server for to refresh access tokens (via refresh tokens).
3. Neither accounts will be duplicated not they be deleted (assuming you have Google Workspace app assigned to these users in Okta), I have a video in this post which shows how to handle the scenario where you have some users directly created in Google Workspace before Okta.
Hope it helps.
hey Goldy, thanks for posting this, it was really helpful.
I’m finding it difficult to use String.replace(user.email,String.substringAfter(user.email,”@”),”gsuitedomain.com”) to replace an incoming domain on its way to google. Okta claims a syntax error:
Invalid expression syntax String.replace(“@”,String.substringAfter(user.email,”@”),”gsuitedomain.com”)
Any clues?
Hi Eddie – thats because it is expecting a string, but you are providing function, you should try this
String.replace(user.email, (String.substringAfter(user.email, “@”)), “gsuitedomain.com”)
Hi Goldy, you produce SO GREAT content…we are happy users of your OKGoldy add-on when we deploy GSuite for our customers (we are a small GSuite Parter consultancy firm)
Regarding OKTA.
If ALL the “Saas” apps that our customer uses, have the option to sign on with their gsuite account, would you still recommend using OKTA?
More and more webapps offer SSO with GSuite….
Thanks a lot
Your welcome Alvaro, glad I could help.
regarding your Otka question : “Sign in with Google” is an OpenID way to login to those other applications, which indeed is more secure, and one should certainly use it being an individual.
However if you are a G Customer, then ideally you should be using SAML (documentation here https://support.google.com/cloudidentity/topic/7558768), not because SAML is better than OIDC, but because Google offers controls on SAML.
For e.g, you can decide who should get access to service applications via your Google Workspace / Cloud Identity id.
Till today, Google does not provide option to block OIDC sign in (Sign as Google) for websites, though you can block OAuth scopes so your users can’t share it with 3rd parties other than their identity (openid scope only), but it still increases a bit of shadow it.
So, today, i would recommend Google as your IdP (via SAML), instead of Okta if you are a Google Workspace / Cloud Identity customer.