authentik and VMware vCenter SSO integration

How authentik and VMware vCenter SSO work together

vCenter accounts often sit apart from the rest of the estate, which means administrator access to the hypervisor layer is managed by a separate set of accounts, passwords and offboarding steps. authentik connects to vCenter through the vCenter Okta identity provider flow, with authentik acting as the OIDC and SCIM provider, on vSphere 8.0 Update 1 or later with VMware Identity Services active. The integration changes how people sign in to vCenter and how their users and groups reach it: sign-in is redirected to authentik, and provisioning can carry users and groups from authentik into vCenter rather than leaving them to be created by hand. The supported method is the one described in the authentik vCenter integration guide, and that guide is the document to follow for the exact configuration sequence.

Several things stay local by design. Break-glass administrator accounts that do not depend on the identity provider are the usual choice, so that a broken authentik instance, expired certificate or misconfigured redirect does not lock every operator out of the hypervisor. ESXi host credentials, vCenter appliance root access and the built-in administrative paths are not replaced by the OIDC sign-in. Confirm with the integration guide and VMware documentation which accounts remain local after the flow is active, and record where each recovery credential is stored and who can use it. Also confirm which vCenter objects receive permissions from provisioned groups, because group membership alone does not define what an operator can do.

What vCenter SSO with authentik needs before setup starts

vCenter SSO through authentik depends on four layers lining up: the vSphere release, the identity service on vCenter, a supported authentik line, and the network and trust between them. Check each one before you open the vCenter configuration, because a gap in any layer shows up later as a failed login rather than a clear error.

vSphere and vCenter version

The authentik vCenter guide requires vSphere 8.0 Update 1 or later. Confirm the exact build your vCenter and ESXi hosts run against the guide's stated requirement, since a minor build can change which identity flow is available. Check this on every vCenter you plan to federate, including any lab or recovery instances. Versions that have left general support cannot be brought onto this flow without an upgrade first.

VMware Identity Services active

The vCenter Okta identity provider flow depends on VMware Identity Services being active in your vCenter. Confirm it is enabled and healthy before planning the rest of the work, and record who owns that service on your vCenter side. If it is not active, the authentik configuration will have nothing to attach to, and the failure may look like an authentik problem.

Supported authentik version

Run authentik on a line that still receives security fixes. The security policy lists 2026.5.x and 2026.8.x as supported, and the project announces security releases at least 24 hours in advance. Plan your window for that notice, and confirm the vCenter guide's tested authentik version before you start, because an unsupported line is a risk even when the integration works.

Running server, worker and PostgreSQL

A working authentik deployment needs the server container, the worker container for background tasks, and PostgreSQL, which holds all configuration and data except uploaded files. Verify all three are healthy and that the authentik admin login works before you create any vCenter-facing provider. For production, use a separately managed PostgreSQL rather than a demonstration database bundled with a chart.

Network paths and DNS

vCenter must reach the authentik URL over HTTPS, and your browsers must reach both. Test name resolution from vCenter itself, not from your workstation, and confirm the firewall rules between the vCenter management network and the authentik ingress. Confirm the exact callback and discovery URLs the guide expects, so the public hostname you publish matches what you register.

Certificate trust and a break-glass admin

vCenter must trust the certificate chain presented by the authentik endpoint, so load the internal CA into vCenter's trust store and test the chain from it. Separately, keep a local vCenter administrator account that works without SSO. Confirm with the guide which vCenter role is needed to create the identity provider and assign administrators, and record who holds that role before you begin.

Configuring the vCenter Okta identity provider with authentik, step by step

This sequence connects vCenter sign-in to authentik through the vCenter Okta identity provider flow, with authentik supplying OIDC sign-in and SCIM provisioning. When it is complete, a test user signs in through authentik and receives the vCenter role granted by their group.

Confirm the vSphere version and identity services
Before any configuration, confirm that vCenter runs vSphere 8.0 Update 1 or later and that VMware Identity Services is active on the vCenter instance. The authentik integration guide requires both, so an administrator should check the version in the vSphere Client and confirm the service status in the vCenter administration views. Record the vCenter version and the planned test group in your change notes. The check is complete when both requirements are confirmed in writing and a vCenter administrator who will keep local access is named.
Create the OIDC provider and application in authentik
In the authentik admin interface, create an OAuth2/OIDC provider and an application that uses it, following the values in the authentik vCenter guide. Set the redirect URI and signing settings exactly as the guide specifies, then note the client ID, client secret and the OpenID discovery URL for the next step. Store the secret in your secret manager rather than in a ticket. The check is complete when the application appears in the authentik application list and the discovery URL returns an OpenID configuration when opened in a browser.
Create the SCIM provider in authentik
Create a SCIM provider in authentik that targets the vCenter SCIM endpoint and attach it to the same application, as the guide describes. The SCIM provider is what pushes users and groups into vCenter, so the endpoint URL and authentication token must match the values vCenter will issue in a later step. Keep the token scoped to this integration only. The check is complete when the SCIM provider is listed under the application's backchannel providers and the configuration saves without validation errors.
Register the Okta identity provider in vCenter
In the vCenter identity provider settings, add an Okta identity provider and enter the client ID, client secret and discovery URL from authentik, using the field names and values the guide lists. Confirm that the provider is saved, enabled and shows the expected issuer. Keep the local vsphere.local administrator account and a separate local administrator active so you can recover access if SSO fails. The check is complete when vCenter reports the identity provider as active and the sign-in page offers the new option alongside local sign-in.
Configure SCIM push to vCenter
Generate the SCIM endpoint and token in vCenter, then enter them in the authentik SCIM provider and run a sync. Watch the authentik sync status and the vCenter provisioning view for errors. Confirm which groups are included in the sync scope so that only intended groups reach vCenter. The check is complete when the sync log reports created accounts and groups, and the matching users and groups appear in vCenter without manual creation.
Assign a test group and map its vCenter role
In authentik, add a test user to a dedicated test group and confirm that the group is part of the SCIM sync scope. In vCenter, grant that group a role on a bounded object, such as a test folder or a read-only permission, rather than a global administrator role. Review each permission before you widen it to production groups. The check is complete when the test group appears in vCenter with the intended role and the role's permissions match the design you documented.
Sign in with a test user and verify access
Sign in to the vSphere Client with the test user through the Okta option, and complete the authentik login, including any MFA policy your authentik flow enforces. Confirm that the session shows the expected user identity and that the user can see only the objects granted to the test group. Then sign in with a user from a group that should have no access and confirm that it is denied. The check is complete when the test user lands in the vSphere Client with the expected permissions and the out-of-scope user is refused.

Mapping authentik users and groups for vCenter SSO

This table compares each authentik object with its vCenter counterpart, the direction of sync, and what it is for. Read it as the checklist to confirm before you fix the mapping, since exact claim and attribute names come from the vCenter guide. The main takeaway is that provisioning moves identities and group membership, but vCenter roles still need assignment inside vCenter.

authentik object	vCenter object	Direction of sync	Purpose
Users	vCenter identity source user	authentik to vCenter (SCIM)	Creates the accounts vCenter will recognize at sign-in. Confirm which user attributes the vCenter guide maps.
Groups	vCenter identity source group	authentik to vCenter (SCIM)	Carries directory groups into vCenter so they can be granted permissions. Confirm the group naming the guide expects.
Group membership	Group membership in vCenter	authentik to vCenter (SCIM)	Keeps vCenter group membership aligned with authentik, so access follows directory changes.
Group claim in the OIDC token	Group membership used at sign-in	authentik to vCenter (OIDC)	Lets vCenter see which groups a user belongs to at login. Confirm the claim name in the vCenter guide before fixing it.
Login identifier claim (for example, username or email)	vCenter login name	authentik to vCenter (OIDC)	Determines the name a user types and the principal vCenter records. Choose one stable value and confirm the claim name.
Group to role assignment	vCenter global or object permissions	Not synced; set inside vCenter	Maps a group to a vSphere role. Synced groups do not grant access until a role is assigned in vCenter.
Deactivated or removed user	Disabled vCenter account	authentik to vCenter (SCIM)	Disables access when the user is deprovisioned. Confirm how the guide handles deletion versus deactivation and existing permissions.

Provisioning users and groups with SCIM, and what recurs

SCIM is the mechanism that pushes users and groups from authentik into vCenter, so the first decision is which system is the source of truth for identity. If users and groups are maintained in authentik and synchronized from an upstream directory, provisioning should follow that path, and vCenter should not become a second place where accounts are created by hand. Before enabling the sync, map each authentik group to the vCenter roles it should carry, and decide which groups are allowed to reach administrative roles at all. That role design is one-time work, but it is the part that is hardest to unwind later, because every group that is provisioned becomes a grant that someone must review. Confirm with the vCenter guide which SCIM attributes and group membership handling the integration expects, and test the mapping in a non-production vCenter first.

Most of the effort recurs after go-live. Group membership changes, joiners and leavers, and access reviews all flow through the sync, so the operations team needs to verify that a disabled user in authentik is disabled in vCenter and that removed group members lose their roles. Credentials and certificates used between the two systems must be rotated on a schedule, and both sides need an upgrade plan. vSphere 8.0 Update 1 or later with VMware Identity Services active is the stated requirement, so any vCenter upgrade can change the identity flow and must be retested against authentik. Keep a break-glass local administrator in vCenter so an identity outage does not lock out the team.

Cost and effort rise with the number of groups and roles, because each combination needs a mapping decision and a test. They also rise with the number of vCenter instances sharing one authentik, since each instance has its own configuration, roles and upgrade timing. Whether your own operations team can run the sync determines how much support a partner would provide after handover. When requesting a fixed-scope quote, ask for the list of groups and roles in scope, the number of vCenter instances and environments, the identity source of truth, the rotation and upgrade responsibilities after handover, and the test and rollback evidence that will be delivered.

Hardening sign-in to vCenter through authentik

Once vCenter trusts authentik for sign-in, the identity provider becomes a path to vSphere administration. The controls below cover recovery access, the accounts that can change the trust, the groups that receive administrator rights, the TLS and credential material behind the connection, and the logs that show who signed in where.

Keep a documented local administrator

Keep a local vCenter administrator account that does not depend on authentik, and record where its credentials are stored and who can retrieve them. If authentik is down, misconfigured or its certificate expires, this account is the only way to repair the identity source inside vCenter. Test the break-glass login after the integration is working, and confirm the account is excluded from any SSO-driven group changes.

Protect authentik administrator accounts with MFA

Anyone who can edit the authentik provider, its groups or its flows can change who receives vCenter access. Require a second factor for every authentik account with administrative rights, and keep those accounts separate from everyday user accounts. Confirm with your team which MFA methods authentik supports for administrators in your version before you enforce them.

Limit and review vCenter administrator groups

Map only the authentik groups that need vSphere administration to vCenter administrator roles, and keep the mapping in a short, named list. Review membership on a fixed schedule, and remove people who have changed roles. Because SCIM provisioning copies group membership, a group that is too broad in authentik grants access in vCenter without any manual step.

Validate TLS trust for the OIDC endpoint

vCenter must trust the certificate presented by authentik's OIDC and SCIM endpoints. Use a certificate chain issued by a CA your vCenter trust store already accepts, and check it from the vCenter appliance before go-live. Do not disable certificate verification to get the connection working, because that removes protection for both sign-in and provisioning traffic.

Store and rotate client credentials

The OIDC client secret and the SCIM token are credentials that let a system act for your identity provider. Keep them in a secrets manager, restrict read access to the people who maintain the integration, and document the rotation procedure before the first rotation is due. Plan the rotation window so vCenter and authentik are updated together, and confirm how your vCenter version handles a changed secret.

Log sign-ins in both systems

Record authentication events in authentik and in vCenter, and forward both to the same log platform so an investigation can follow one user across the two systems. authentik's enhanced audit logging is listed as an enterprise-only feature on its pricing page, so confirm with the vendor whether the open-source edition captures the events you need before you rely on it for review.

Which vSphere version path changes the work

If your vCenter is on vSphere 8.0 Update 1 or later and VMware Identity Services is active, the authentik vCenter guide applies directly. The connection uses the vCenter Okta identity provider flow, with authentik acting as the OIDC and SCIM provider. Your first task is planning the configuration, not upgrading the platform.

Confirm the exact build: Check the vCenter version and update level in the management interface before you open the guide.
Confirm VMware Identity Services: Verify it is active in your environment, since the flow depends on it.
Plan the group model: Decide which authentik groups map to vCenter roles before provisioning starts.
Schedule a test vCenter path: Test sign-in on a non-production vCenter first where one exists.
Keep a local administrator: Retain a break-glass account outside SSO so you can recover if the identity flow fails.

Before you start, confirm the version and identity services status with your VMware administrator, and record the result in your change plan.

Failures that stop vCenter sign-in or user sync

This table pairs common vCenter sign-in and SCIM sync failures with their likely causes and fixes. Start from the symptom column, check the cause, then apply the fix and confirm it against the logs in both vCenter and authentik before retrying users.

Symptom	Likely cause	Fix
Redirect or callback error after clicking sign-in	The redirect URI registered in the authentik OAuth2/OIDC provider does not exactly match the callback vCenter sends, often because of host name, port or trailing slash differences.	Copy the redirect URI from the vCenter guide in the authentik integrations catalog, match it character for character, and compare the request in authentik and vCenter logs before retesting.
vCenter does not offer the authentik identity provider	VMware Identity Services is not active, or vCenter is below vSphere 8.0 Update 1, which the authentik guide requires.	Confirm the vCenter build and that VMware Identity Services is active, then retry the identity provider setup. Use the vCenter guide to confirm the exact requirement for your build.
TLS handshake or certificate trust failure to authentik	vCenter does not trust the certificate chain presented by the authentik endpoint, often because of a private certificate authority or an incomplete chain.	Install the internal CA chain in the vCenter trust store as the guide describes, then verify the authentik discovery URL is reachable from vCenter over HTTPS.
Users missing after a SCIM push	The user or group is not assigned to the authentik application, so authentik never sends it to vCenter.	Check the application's bindings in authentik, assign the required group, trigger a sync, and review the SCIM provider task logs for skipped objects.
Administrator locked out after a bad configuration	An incorrect identity provider change or a mismatched group mapping removed every working administrative path.	Keep a local vCenter administrator account and document the break-glass path before changing SSO. Use it to revert the identity provider setting, then correct the mapping in a test window.
Token validation fails intermittently	Clock skew between vCenter, authentik and the directory servers makes tokens appear expired or not yet valid.	Synchronize all servers with the same trusted time source, verify offsets in both systems' logs, and retest sign-in after correction.
Duplicate accounts with the same name	Local vCenter users share a name with users provisioned from authentik, so vCenter treats them as separate identities.	Inventory local accounts before enabling SCIM, decide which identity remains authoritative, and remove or rename duplicates following the guide. Keep the break-glass account excluded from cleanup.

What buyers ask before connecting vCenter SSO to authentik

What drives the effort and cost of connecting vCenter to a running authentik?

When authentik is already running and healthy, the cost depends mostly on the vCenter side of the work and on how many groups you map to vCenter roles. The main cost components are the people who configure and test the integration, the change window your operations team needs, and any remediation found during review. Effort rises if you must set up the OIDC and SCIM provider settings for a new environment, map several directory groups to different vCenter roles, or verify break-glass access for more than one vCenter. Effort also rises if authentik itself has pending upgrades, because the vCenter flow depends on a current, supported authentik release. Ask for a quote that splits the work into one-time items (initial configuration, testing and documentation) and recurring items (later group changes, certificate renewals and version upgrades).

Can our internal team set up vCenter SSO with authentik on its own?

Often yes, if the team already runs authentik and vCenter and has people comfortable with OIDC and SCIM concepts. The work needs skills in four areas: authentik administration (applications, providers, groups and provisioning), vSphere administration (identity sources, VMware Identity Services and role assignment), certificate and DNS handling, and a test plan that proves login, user provisioning and user removal behave as expected. Gaps usually appear in the vSphere identity configuration and in troubleshooting token or certificate errors, because a mistake can lock administrators out of the console. Before starting, decide who owns the change, who can roll it back, and whether a second person reviews the configuration. An outside partner is most useful when none of these skills sit in the team or when you want a written runbook and a tested rollback. Confirm each step against the authentik vCenter guide and your own vSphere build.

How long does the vCenter SSO integration take, and what changes it?

The duration depends on factors your environment sets, so confirm it against your own prerequisites rather than a generic figure. The first factor is the vSphere version: the authentik guide requires vSphere 8.0 Update 1 or later with VMware Identity Services active, so a vCenter on 7.x needs an upgrade first. Broadcom's knowledge base states that general support for vSphere 7.x ended on October 2, 2025, so that upgrade may already be on your roadmap. The second factor is how many prerequisites are complete: a working authentik instance on a supported release, DNS names, certificates that the vCenter and browsers trust, and a directory holding the groups you want to map. The third is the change window your operations team allows, and the fourth is how many vCenter instances share one configuration. Ask for a schedule that lists each prerequisite check as its own milestone, so the time spent is visible.

What must our team provide before the integration begins?

Before work starts, your team should provide administrator access to authentik and to each vCenter in scope, plus credentials for any directory that supplies the groups. The usual items are:

An authentik administrator account with rights to create applications, providers and groups.
vCenter administrator access, including the ability to configure identity sources and assign roles.
Two or three test users with known group memberships, so access can be checked for each role.
DNS records for the authentik and vCenter hostnames, plus a plan for the redirect addresses both systems use.
Certificates for the authentik and vCenter endpoints that the browsers and vCenter trust.
A change window agreed with operations, with a named person who can approve a rollback.

Confirm the exact list against the vCenter guide, because its setup steps determine the names and values you need.

Does connecting vCenter to authentik require an authentik Enterprise subscription?

The information available here does not establish that the vCenter guide requires an Enterprise subscription, so confirm this in the guide and on the pricing page before you commit. The pricing page lists three editions: Open Source at no cost, Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. The Enterprise-only features it lists include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support. None of those names the vCenter integration. authentik's code is under the MIT license, except code in the enterprise directory, which has its own license. Ask for written confirmation of the edition the vCenter flow needs for your user count, and of the support tier you need if an SLA matters to you.

Does vCenter SSO with authentik change our vSphere licensing or force an upgrade?

The integration itself does not change your vSphere licensing, but your current vSphere version and support status can force an upgrade. The authentik guide requires vSphere 8.0 Update 1 or later with VMware Identity Services active, so an older vCenter must be upgraded first. Separately, Broadcom ended the availability of perpetual licensing, moving customers to subscriptions at renewal, and states that Enterprise Plus, vSAN, NSX, Site Recovery Manager and Aria Suite are offered only as part of VMware Cloud Foundation or VMware vSphere Foundation. Broadcom's knowledge base explains that hosts and vCenter on perpetual licenses keep running after support expires, but new patches and major version upgrades require an active support contract. Before scheduling the work, check your entitlements, support end dates and the edition you own, because the required upgrade may depend on a subscription you do not yet hold. Ask your vSphere vendor or reseller to confirm these points against your contract.

How DeployOpen scopes and delivers the vCenter integration

DeployOpen plans, builds, tests and documents authentik and VMware vCenter SSO integration inside your own infrastructure, with the vSphere version, VMware Identity Services state and provisioning model confirmed before any configuration starts. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first.

How we scope

Confirm your vSphere and vCenter version against the 8.0 Update 1 requirement and whether VMware Identity Services is active
Record which vCenter roles, groups and identity sources must map to authentik users and groups, and who approves them
Agree in writing whether the scope includes the authentik OIDC and SCIM provider, the vCenter Okta identity provider setup, testing and documentation

How we build

Configure the authentik OIDC and SCIM provider, redirect URIs and group claims in a lab that mirrors your vCenter topology first
Test sign-in, provisioning and group-to-role mapping with named test accounts before any production change
Keep a local vCenter administrator path documented and verified so an SSO fault does not lock out administrators

How we hand over

Deliver written configuration records covering provider settings, claim mappings, role assignments and the break-glass procedure
Walk your operators through provisioning checks, sign-in troubleshooting steps and where authentik and vCenter logs are read
Document upgrade checkpoints for authentik and vSphere so your team can plan changes without guessing at compatibility

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover
Retainer scope can cover re-testing after authentik security releases and vSphere patch cycles that affect the integration
Ask for a quote built from the written scope, listing one-time build effort separately from any recurring retainer work