Skip to content
Avanet

Configure OpenID Connect and Okta for Sophos Central SSO

Sophos Central can use an OpenID Connect provider for SP-initiated Single Sign-on. Sign-in starts at Sophos Central and is redirected from there to the identity provider. An IdP-initiated dashboard link alone is therefore not a valid functional test.

Prerequisites

Requirements include a Super Admin, a domain verified in Central, a tested fallback administrator, and an OIDC provider that accepts the authorization requests expected by Sophos. Every affected Central account must be assigned to one domain and exactly one identity provider.

Central requires four provider values:

FieldMeaning
Client IDPublic identifier of the OIDC application created for Sophos Central
IssuerExact issuer URL whose value matches the iss claim in the ID token
Authz endpointHTTPS endpoint for the authorization request
JWKS URLHTTPS endpoint containing the provider’s public signing keys

The callback URL is exactly https://federation.sophos.com/login/callback. Sophos requests openid profile email, response_type=id_token, and response_mode=form_post. The provider must return an ID token; Sophos does not request an authorization code in this flow.

Configure the Okta app

In the Okta Admin Console, create an application under Applications > Create App Integration:

  1. Select OIDC – OpenID Connect, then Single-Page Application.
  2. Assign a unique name such as Sophos Central SSO.
  3. Under Grant type, clear the core grant Authorization Code.
  4. Under Advanced > Other grants, enable Implicit (hybrid).
  5. Enter https://federation.sophos.com/login/callback as the Sign-in redirect URI.
  6. Remove existing Sign-out redirect URIs.
  7. Initially restrict assignment to a defined pilot group. Sophos shows all organization users as a simple example; a pilot group provides a more controlled rollout.
  8. Save and record the Client ID.

The selected Okta Authorization Domain provides the Issuer. With a Custom Domain, for example, it may be https://login.example.com. This normally produces:

Issuer:         https://login.example.com
Authz endpoint: https://login.example.com/oauth2/v1/authorize
JWKS URL:       https://login.example.com/oauth2/v1/keys

Do not copy values from an example. Verify them against discovery or provider configuration in the actual Okta tenant. An Issuer using a different Authorization Server may have different paths.

Create the provider in Sophos Central

  1. Open Global Settings > Access Control > Sign-in and Identity > Federated identity providers.
  2. Select Add identity provider and enter a name and description.
  3. Select Type: OpenID Connect and the matching vendor, such as Okta.
  4. Enter the Client ID, Issuer, Authz Endpoint, and JWKS URL exactly.
  5. Select the verified domain. Multiple domains are possible, but a user remains assigned to exactly one.
  6. Select IdP enforced MFA only when the provider guarantees MFA for all affected identities. Otherwise, use No IdP enforced MFA.
  7. Save, reopen the provider, and enable it with Turn on after configuration is complete.

Sophos lists OIDC as a possible provider for Google Workspace but does not supply a comparable complete field set in the Central guide. Obtain the values from the actual Google or Cloud Identity OIDC configuration and validate them in the pilot. Do not transfer Okta paths to Google.

Sign-in mode and pilot

Under Sophos sign-in, first select the parallel mode with a Sophos password and federated credentials. Test at least these cases:

  • valid pilot user with IdP MFA,
  • user without app assignment,
  • incorrect or unverified domain,
  • expired IdP session,
  • sign-out followed by a new SP-initiated sign-in,
  • second Super Admin through the fallback path.

Consider Federated credentials only only after a successful pilot. Assigning the IdP app to every user does not replace checking that each Central account is assigned to the correct domain and provider.

Troubleshooting

  • Invalid redirect or sign-in loop: Check callback, application type, and the implicit ID-token flow.
  • Unknown issuer: The iss value in the ID token must match Central’s Issuer field exactly.
  • Signature cannot be verified: Check the JWKS URL, HTTPS availability, and currently published key.
  • User is not found: Compare the email claim, Central email address, and domain assignment.
  • Provider cannot be enabled: Required fields, the domain, or a URL format is incomplete or invalid.
  • MFA is missing or appears twice: Review the IdP policy together with Central’s IdP enforced MFA selection.

Sign-in Rules, break-glass access, MFA recovery, and changing the tenant mode are explained in Secure Sophos Central sign-in with MFA, passkeys, and an IdP.

Frequently asked questions

Does Sophos Central support the Authorization Code Flow?

For this OIDC flow, the current Sophos guide describes an implicit request using response_type=id_token without requesting an authorization code. The provider app must match this documented behavior exactly.