Set up Google Workspace OIDC on Sophos Firewall

With SFOS 23.0, you can configure Google Workspace as an OpenID Connect (OIDC) identity provider for WebAdmin, Captive Portal, VPN Portal, Remote Access IPsec and SSL VPN. Google verifies the identity; the firewall also retrieves group memberships and applies its own user, VPN and administrator permissions. A successful Google sign-in alone therefore does not grant administrator access or access to an internal network.

Quick setup: Prepare a Google OAuth web client and a delegated service account, create an OpenID Connect server with IdP vendor: Google Workspace under Authentication > Servers, register the callback URLs displayed there with Google, import groups and switch only the required services under Authentication > Services. Then use a pilot account to check sign-in, permissions and logs. Retain the tested local emergency access method.

This guide describes the SFOS 23 configuration; it does not guarantee support in any particular released firmware build. Before updating, follow your own firmware and backup planning. Chromebook SSO and Google Directory Sync for Sophos Fusion are separate integrations and do not replace this firewall OIDC server.

Prerequisites and security boundaries

Confirm responsibilities and record the existing configuration

You need a Google Cloud project, a Google Workspace account with Super Admin access for setup, and a firewall administrator. Cloud Console manages the OAuth client, APIs and service account; Google Admin Console manages users, groups and Domain-wide delegation.

Before the pilot, prepare a configuration backup and a tested local recovery access method. Also record the existing authentication servers and their order for each service, portal hostnames, Device Access permissions, group and VPN assignments, and existing admin profiles. Keep a full-administrator session open during the change; because it may time out, it is not a substitute for the second access method.

Before the first pilot sign-in, record under Authentication > Users whether each affected local account already exists, along with its current User type, assigned Profile and account status. This per-account record forms part of the previously recorded state: a later change to the IdP mapping or Google role does not automatically restore existing local administrator accounts to their previous state.

The guidance on personal administrators and Device Access profiles still applies when planning permissions. Google SSO replaces neither least privilege nor restrictions on management sources.

Use a consistent hostname

The portal name must belong to a registrable domain with a public TLD. A single-label name such as firewall or a local domain such as firewall.local is unsuitable for Google OAuth redirects. Use the same FQDN for portal access, redirect URIs and automatic portal redirects. Check DNS resolution and a trusted HTTPS certificate matching the name from the client networks that will actually be used.

fw.example.com is used here only as a documentation example and must be replaced with your own valid FQDN. It is not a complete redirect URI. Later, copy the callback path and service port unchanged from Show URLs, rather than constructing them from an example. For this procedure, use an FQDN even when entering it manually, not an IP address.

Check limitations before switching

Only one OIDC IdP server can be selected for each authentication service. An existing Entra assignment must therefore be deliberately replaced or left unchanged, rather than simply supplemented.
Users for the same domain cannot be synchronised through both Active Directory and Google Workspace at the same time. Existing users and groups need matching Google objects; legacy objects that cannot be mapped must continue to be managed manually.
The firewall’s own MFA is not used for Google OIDC. Configure the MFA requirement in Google and verify it during the pilot. Local emergency accounts retain their own protection.
In an HA cluster, Google SSO currently does not support WebAdmin sign-in on the auxiliary device. An independent local management access method remains necessary for this.
Google SSO with Sophos Connect requires Windows and client version 2.4 or later. Entra support on macOS does not imply Google Workspace support.

Only if Context-Aware Access (CAA) is to be used: Before the pilot, check that each intended user has a CAA-supported licence/edition, that the specific application and sign-in flow are supported, and that the required policy is actually assigned to the application and user group/organisational unit. Users with other editions are not subject to the CAA policy, even if the same group or organisational unit is targeted; Endpoint Verification alone does not establish CAA entitlement. CAA is optional and is not a premium licence requirement for ordinary Google OIDC. Google SAML documentation does not establish support for the Sophos OIDC flow. Before approving the rollout, demonstrate the intended enforcement with fresh positive and negative sign-in tests for the specific application, users and conditions; missing support or an unexpectedly successful negative test blocks approval of the CAA-protected flow.

Prepare Google Workspace

Create an OAuth web client

Select the correct project in Google Cloud Console > APIs & Services > Credentials. If Google first requires you to configure the OAuth consent screen, complete it for your organisation and the approved user population; do not enable general external access merely for testing.
Open Create credentials > OAuth client ID and select Application type: Web application.
Assign a recognisable name, such as SFOS-Google-SSO-Pilot, and create the client.
Immediately store the Client ID and Client secret in an approved secrets vault. Do not copy the secret into screenshots, tickets or change documentation.

The OAuth client ID identifies the firewall during sign-in. It is not the numeric service account ID required later for delegation. Add the redirect URIs only after the firewall has generated them.

Set up the service account and group lookup

Sign-in and group lookup use different credentials: the OAuth client handles interactive sign-in; the service account allows the firewall to retrieve Google Directory information. Google does not simply supply group memberships as part of the standard OIDC sign-in response.

Create a dedicated account for this integration under Google Cloud Console > IAM & admin > Service accounts > Create service account, for example sfos-directory-reader.
Do not assign blanket Owner or Editor roles as a supposed prerequisite. Approve additional IAM permissions only for a demonstrated task.
Note the numeric Unique ID in the service account details.
Under Keys > Add key > Create new key, select JSON. Keep the downloaded private key secure for later upload to the firewall and avoid uncontrolled download copies.
Under APIs & Services > Library, find Admin SDK API and activate it with Enable.

⚠️ If Service account key creation is disabled appears, stop the setup. Do not disable an organisation policy across the entire organisation to continue with this guide. The Google security owner must approve a limited, documented exception, or the integration remains blocked. The Sophos configuration described here requires a JSON key file; no other authentication method is presented as an unverified substitute.

Restrict Domain-wide delegation

As an authorised Super Admin, open Google Admin Console > Security > Access and data control > API controls.
Under Domain-wide delegation > Manage domain wide delegation > Add new, enter the service account’s Unique ID as the Client ID, not the OAuth web client ID.
In OAuth scopes (comma-delimited), enter the two required read scopes:

https://www.googleapis.com/auth/admin.directory.group.readonly,https://www.googleapis.com/auth/admin.directory.group.member.readonly

If WebAdmin will also authenticate through Google, add this scope as well:

https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly

Save the delegation with Authorize and check the ID and complete scope list.

The scope URLs are fixed API identifiers, not example values. If Multi-party approval is active, another Super Admin must approve the delegation. Changes can take up to 24 hours; do not prematurely create a second delegation with broader permissions during this period. Domain-wide delegation permits access on behalf of users in the Workspace tenant and is therefore security-sensitive even with read-only permissions. Assign a named owner to the service account, key ID, delegated administrator account, purpose and review date.

Prepare separate firewall admin groups

Group mapping is recommended for a straightforward initial setup. Under Google Admin Console > Directory > Groups, create a group exclusively for firewall administrators and add only the pilot administrators. For example, a group named SFOS-NOC-ReadOnly can be assigned to a previously verified read-only profile. The name and group address are organisation-specific values; an ordinary employee or VPN group must not receive WebAdmin permissions.

Alternatively, you can assign custom or predefined Google admin roles under Account > Admin roles and use Roles in the firewall server configuration. Custom roles are mapped using their exact role name; predefined roles require their specific IdP value, not simply the displayed label. One confirmed example is Groups admin → _GROUPS_ADMIN_ROLE. Google admin roles can also grant permissions in Google Admin Console. Do not therefore assign them solely as convenient firewall labels; a dedicated group is usually the more narrowly scoped choice.

Configure the OIDC server on the firewall

Client, redirects and endpoints

Open WebAdmin using the planned FQDN and go to Authentication > Servers > Add.
Select Server type: OpenID Connect, a unique Server name and IdP vendor: Google Workspace.
Enter the OAuth web client’s Client ID and Client secret.
Under Redirect URIs, select Use firewall URL. The firewall uses the hostname from the current WebAdmin URL. Alternatively, use Enter manually to enter your own verified FQDN.
Open Show URLs and copy the complete URLs for Web admin console, Captive portal or VPN portal and remote access, as appropriate for the services you actually plan to use.
Leave the automatically configured Issuer URL https://accounts.google.com unchanged and use Discover/Reset endpoint URLs. Authorization URL, Token URL, Logout URL, JWKS URL and User info URL are populated through discovery, not guessed.

Identity, fallback and admin permissions

Under User attributes, Display name and Username support the values name or email; the documented default for both is name. Email address is preconfigured with email. Make this decision before the first pilot sign-in: email can simplify mapping to a unique Workspace sign-in address, but must match existing firewall identities. Do not casually change attribute values later, as this can result in different account mappings.

For VPN-only or Captive Portal-only use, leave IdP authentication for firewall administrators disabled. For WebAdmin, deliberately enable the option and create each mapping with IdP attribute, the exact IdP value and Device access profile. Take group or role values from your own Google configuration rather than guessing them from the example name.

The firewall checks mapping rules from top to bottom and uses the first matching profile. A user in several admin groups must therefore be explicitly tested. Without a matching admin mapping, the identity receives no WebAdmin access and may be created as a normal user.

Under Fallback group, choose a deliberately restricted user group. If the Google group does not exist on the firewall, this fallback group is used. Even if the server is selected under Firewall authentication methods, Default group does not replace this OIDC fallback assignment. A VPN group with broad permissions is not a safe catch-all.

Check the service account and align hostnames

Under Service account credentials > Email address, enter the address of the Google Workspace Super Administrator designated for this access. The service account’s email address does not belong here.
Under JSON private key > Browse, select the securely stored JSON key file for the dedicated service account.
Run Test connection. The test checks network connectivity and application permissions. It does not yet prove that user sign-in or admin mapping is correct.
Save with Save.
Use Go to Admin and user settings and, under When redirecting users to the captive portal or other interactive pages, set the identical portal FQDN: Use the firewall’s configured hostname or Use a different hostname, as appropriate for your configuration. Save with Apply.
In Google Cloud Console > APIs & Services > Credentials, open the OAuth web client and enter each previously copied complete callback URL under Authorized redirect URIs > Add URI. Save with Save and compare them character by character.

Enable groups, services and VPN

Import groups and assign policies

Under Authentication > Servers, open the Google server’s Assistant for importing groups. You can import all groups or select specific groups using Display name and Mail. For the pilot, select only the required users’ groups. In the assistant, you can assign Surfing quota, Access time, Network traffic and Traffic shaping to all or individual groups.

The firewall and Google must have synchronised time; otherwise, even the group import can fail. After the import, check the group names and intended policies. For IPsec or SSL VPN, the new groups must also be added to the relevant VPN policies. A successful import does not itself grant VPN access.

Switch authentication for each service

Under Authentication > Services, select the Google server only for the required methods:

Administrator authentication methods: WebAdmin.
Firewall authentication methods: Captive Portal.
VPN portal authentication methods: VPN Portal.
VPN (IPsec/dial-in/L2TP/PPTP) authentication methods: Remote Access IPsec; the list label does not imply OIDC support for every legacy protocol named in it.
SSL VPN authentication methods: Remote Access SSL VPN.

Drag the server to the top of the list for the selected service and use Apply for each service. Check the order and local fallback against the previously documented state; do not inadvertently remove Local for personal local administrators. Leave services that are not required unchanged.

Sophos Connect and connectivity

Google SSO also uses the VPN Portal port for remote access communication. For this use, VPN Portal access from WAN must be allowed under Administration > Device access > Local service ACL. Deliberately plan the permitted sources and the connectivity actually required; do not open WebAdmin to WAN for this purpose. Device Access and Local Service ACL explains these restrictions.

When using a provisioning file, IPsec, SSL VPN and VPN Portal must use the same Google server. The gateway value corresponds to the FQDN used to generate the redirects. Without a provisioning file, SSL VPN and VPN Portal must still use the same server; IPsec can use a different Google server. Do not therefore blindly change only an authentication field in existing VPN files.

After the Google configuration is set up or changed, Windows users must re-import their configuration file into Sophos Connect 2.4 or later. Only then should a fresh connection be tested. On shared endpoints, force a new SSO sign-in for subsequent users; an existing Google session must not silently sign in the next person.

Optional: use Captive Portal securely

The relevant user-based firewall rule requires Match known users and Use web authentication for unknown users. Under Authentication > Web authentication > Captive portal behavior, enable Show web page after sign-in, select In new browser window, and disable Use insecure HTTP instead of HTTPS for this portal flow. Save with Apply; OIDC does not support this insecure HTTP mode.

Users must leave the Captive Portal window open so they can explicitly sign out. Inactivity or closing a tab does not end the Google SSO session here as it does with other portal methods. After sign-out, the Google sign-out page remains visible. Credential login with a username and password is not a substitute for this token-based Google OIDC flow.

Validation treats connectivity, identity and authorisation separately. Record all tests with the time, account, service, client version and expected result, without recording secrets or tokens.

Successfully complete Test connection and a targeted group import. Then open a private browser window using the intended FQDN.
Sign in a pilot administrator through Google and check the expected MFA requirement. Under Authentication > Users, the identity, administrator status and assigned profile must be correct.
Positively test access to required menus and negatively test access to a restricted area. A read-only account must not be able to save a change. A normal VPN account must not be able to sign in to WebAdmin.
Test an account that matches several mapping rules. Its profile must correspond to the documented first matching rule, not the supposedly strongest role.
Sign in separately to VPN Portal and establish an IPsec or SSL VPN tunnel using the newly imported Sophos Connect configuration. An approved internal resource must be reachable; an unapproved resource must remain blocked.
Sign out and test again with a new session. Google sign-in, portal access and the VPN tunnel are separate success criteria.
Correlate WebAdmin events in Log viewer > Admin and Captive Portal, VPN Portal, IPsec and SSL VPN sign-ins in Log viewer > Authentication. For further analysis, oauth_sso_svc.log is available in the Advanced Shell; no debug or restart commands are required for this.
Check the independent local recovery access method again before migrating more users.

Admin accounts are created or updated only upon a successful WebAdmin sign-in. A VPN or Captive Portal sign-in does not synchronise an administrator role. Google role changes must therefore be validated through a new WebAdmin sign-in, not on the basis of a successful tunnel.

Troubleshoot specific failures

Google reports redirect_uri_mismatch

Compare the complete affected URL from Show URLs with Authorized redirect URIs for the OAuth client actually in use: the scheme, FQDN, port and path must match exactly. Then check whether the browser uses the same hostname and the automatic portal redirect points to that name. After correcting it, test a fresh sign-in; neither wildcard redirects nor switching to an IP address is the solution.

Test connection or group import fails

First check system time and network connectivity. Then verify Admin SDK API, the valid JSON key file, the correct delegated Super Admin account and Domain-wide delegation with the numeric service account ID and required scopes. If groups are missing, also check the Display name/Mail import filter. Do not attempt to resolve an error by granting blanket Cloud Owner permissions or additional write scopes.

Check group membership or role assignment in Google, IdP authentication for firewall administrators, the exact IdP value, the mapping order and the local Device access profile. Then perform a new WebAdmin sign-in and check Log viewer > Admin. A previous VPN sign-in proves neither that the mapping is correct nor that the administrator has been updated.

The portal works, but the tunnel or internal resource does not

Check the Windows and Sophos Connect versions, the newly imported configuration file, VPN Portal connectivity and the server assignment for each service. Then check group membership in the VPN policies and the rules for the target resource. Log viewer > Authentication shows the sign-in; a successful authentication entry alone does not prove that traffic is allowed.

Context-Aware Access or reauthentication behaves differently from expectations

Device-based Google CAA conditions require a supported browser flow and endpoint verification data that is actually available. For the verification procedure described here, use Google Chrome with Endpoint Verification. A successful Sophos Connect sign-in is not treated as proof that every device-based CAA condition was evaluated.

CAA is evaluated during authentication and does not terminate an already active firewall session. Google’s reauthentication interval likewise does not force an active firewall VPN session to sign in again. Test a new authentication after a controlled sign-out or disconnection; existing sessions must be handled separately during offboarding.

Operation, offboarding and rollback

Check any change to groups or roles with a fresh sign-in and positive and negative tests. When removing someone from administration, changing their Google role alone is insufficient: SFOS does not automatically convert an existing administrator account back into a normal user. After checking dependencies, and with another working administrator available, delete the relevant administrator account on the firewall. At the next normal sign-in, the firewall can recreate the user. Check and terminate active WebAdmin and VPN sessions separately; removing group membership is not a proven means of immediately revoking sessions.

Define an owner, secure storage, review and rotation for the OAuth secret and service account key. During a planned rotation, keep the old key available only as long as the documented rollback requires. First test the new credentials with Test connection, group retrieval and a fresh sign-in before revoking the old credentials. A compromise, however, must be handled according to your own incident process, rather than prolonged for the sake of convenient rollback.

If the pilot fails, use the open full-administrator session or local recovery access to restore the exact previously recorded service assignments and server order. Likewise, restore changed portal hostnames, Device Access, group/VPN policies and admin mappings to their respective previous states. Then test local admin sign-in and the previous VPN access method in new sessions.

Also use the independently available full-administrator access method to compare each affected account under Authentication > Users with the per-account record. For existing accounts, explicitly restore the previous User type, assigned Profile and account status; if deletion and recreation are necessary to do this, first check all dependencies and preserve the previous assignments. Remove administrator/user objects created solely for the pilot only after checking their group, VPN, policy and other dependencies. Restoring a server mapping or removing a Google role does not replace this account clean-up and does not terminate any existing session. Active WebAdmin, portal and VPN sessions must therefore be checked and terminated separately. Finally, use fresh sessions to demonstrate that the previous local administrator and VPN access methods work and that a pilot identity which is no longer authorised is denied access; for restored existing accounts, verify that their original permissions are retained and that the additional permissions granted only during the pilot are denied.

Only after rollback works and no other services depend on them should you carefully remove the redirect URIs, delegation grants and credentials created solely for the pilot. Do not delete shared clients or service accounts without checking dependencies. Restore a complete configuration backup only within the approved recovery window, because it can also undo unrelated firewall changes.