Authentication Mechanisms

To perform operations in the vSphere environment, principals must authenticate to the
vSphere Automation
services. You can use the default
vCenter Single Sign-On
identity source or federate your
vCenter Server
to an external identity provider such as Microsoft Active Directory Federation Services, Okta, or Azure AD.
As a result from authenticating to the
vSphere Automation
services, client applications and users receive a session identifier. You can choose from several supported authentication mechanisms to obtain a session identifier that grants you access to the
vSphere Automation
services in the virtual environment.

Choosing Your Identity Source

First, you must decide whether to authenticate to
vCenter Server
by using the default identity provider,
vCenter Single Sign-On
, or leverage your enterprise configuration to an external identity provider.

Default or External Identity Provider

vCenter Server
acts as the default identity provider, by using its built-in
vCenter Single Sign-On
service to authenticate users and service accounts.
In vSphere 7.0 and later, you can delegate vSphere identity management to an external identity provider and take advantage of increased security and multifactor authentication. In this scenario,
vCenter Single Sign-On
is replaced by an external identity provider as the entity that performs principals' authentication.
Identity provider federation enhances the security and compliance of your applications and provides access to flexible benefits such as multifactor authentication (MFA) and automatic account synchronization.
You can federate
vCenter Server
authentication to:
  • AD FS (starting in vSphere 7.0)
  • Okta (starting in vSphere 8.0 Update 1)
  • Azure AD (starting in vSphere 8.0 Update 2)

Basic or Token-Based Authentication

You can use basic and token-based authentication to authenticate principals to the
vSphere Automation
services. VMware encourages you to use token-based authentication as it provides more security and flexibility for your applications and users.

Basic Authentication

Basic authentication passes a user name and password to
vCenter Server
.
By default, principals can use the
vCenter Single Sign-On
user name and password to connect to the
vSphere Automation
endpoint. The
vSphere Automation
endpoint checks whether the user name and password are present in the VMware Directory Service. On success, the system returns a session identifier for the
vSphere Automation
endpoint.
If your
vCenter Server
is federated to an external identity provider, you can use basic authentication through the OAuth 2.0 Password grant type.
VMware encourages you to refrain from using basic authentication and adopt token-based authentication, as it is more secure and provides more flexibility.

Token-Based Authentication

Token-based authentication involves the use of an encrypted token that provides authentication and authorization data to the
vSphere Automation
endpoint. The
vCenter Server
token complies with the Security Assertion Markup Language (SAML) specification, an XML-based schema for communicating authentication data.
To acquire a SAML token, client applications issue a token request to
vCenter Single Sign-On
. Client applications then send the SAML token to the
vSphere Automation
API endpoint in exchange for a session identifier.
Starting with vSphere 7.0, you can use token-based authentication for your federated
vCenter Server
through a 3-step process:
  1. Principals use the various OAuth 2.0 grant types with the external identity provider to obtain identity and access tokens in JSON Web Token (JWT) format.
  2. Principals exchange the JWT tokens for a
    vCenter Single Sign-On
    SAML token.
  3. Principals use the SAML token to obtain a session identifier from the
    vSphere Automation
    endpoint.
For code examples of authentication with the various OAuth 2.0 grant types, see the
vsphere-automation-sdk-java
VMware repository at GitHub.