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)

For more information, see Identity Provider Federation for vCenter Server.

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.

Important:

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.