If your vCenter Server is federated to an enterprise identity provider, such as Microsoft Active Directory Federation Services (AD FS), Okta, or Azure AD, you authenticate by using the OAuth 2.0 grant types. The vSphere implementation of OAuth 2.0 uses the OpenID Connect (OIDC) authentication protocol.
vCenter Server External Identity Provider Support
vCenter Server supports the following external identity providers:
- AD FS (vSphere 7.0 and later)
- Okta (starting in vSphere 8.0 Update 1)
What is OAuth 2.0
OAuth 2.0 is an open authorization standard that allows information exchanges among web services without exposing sensitive data such as user names and passwords. OAuth 2.0 boosts security and prevents malicious actors from stealing users' credentials over the Internet. OAuth 2.0 is an open standard and can be customized according to the organizational requirements.
You can use different OAuth 2.0 grant types to authenticate your applications to vCenter Server. The OAuth grant types represent different methods by which a principal can obtain an access token from an authorization server. In the vSphere implementation, the access token is used to obtain a SAML token and authenticate principals to vCenter Server.
OAuth 2.0 Grant Types
- Password
-
In the Password grant type, the client application exchanges the user's credentials, user name and password, for an access token, and optionally an ID token (JWT tokens), from the authorization server. OAuth 2.0 has been designed to prevent the exchange of user credentials, so the Password grant type must be avoided whenever possible, especially for third-party application authentication. The latest OAuth 2.0 Security Best Current Practice recommends avoiding the Password grant type altogether. As a single-factor method, the Password grant type is incompatible with the requirements of multifactor authentication (MFA). For more information, see Authenticate to an AD FS-Federated vCenter Server by Using the Password Grant Type.
Important: The Password grant type is disallowed by the latest OAuth 2.0 Security Best Current Practice. The Password grant is excluded entirely from OAuth 2.1. - Authorization Code
-
In the Authorization Code grant type, the client application uses an authorization code to obtain JWT tokens from the authorization server. This grant type requires a user to verify an authentication request through a web browser. The Authorization Code grant type is compatible with multi-factor authentication and guarantees a substantial degree of security. This grant type is appropriate for regular web applications running on a server. For more information, see Authenticate to an AD FS - Federated vCenter Server by Using the Authorization Code Grant Type.
- Client Credentials
-
The Client Credentials grant type permits web services to authenticate to other web services without the involvement of a user. This grant type is useful for applications that are resource owners and can take advantage of headless, or backend automation, when a physical user is not present. For example, a client application might use this grant type to authenticate and fetch details about a virtual environment.
- Refresh Token
-
The Refresh Token grant type is used by clients to exchange an expiring access token for a refresh token that can be used to receive a new access token. With this grant type, a client application can fetch a valid access token without asking the user to log in again. It allows client applications to provide a seamless user experience without further interaction with the user after timeouts.
What Is OpenID Connect (OIDC)
The vSphere implementation of OAuth 2.0 uses the OpenID Connect (OIDC) authentication protocol. With OIDC, the authorization server returns an ID token containing data about who the users are and what permissions they have on the resource server. As a result, vCenter Server can identify users and grant them the respective permissions that are defined on the authorization server.
