VCF 9.1 API Access (7): Balancing Operational Simplicity with IdP Governance

On By David ZhangIn Cloud Foundation

VCF 9.1 API Access Series

This post is part of an ongoing deep-dive series on VCF 9.1 programmatic access.

Foundational Mechanics

Component Authentication & Token Exchange

Advanced Architecture, Governance & Least Privilege

Day-2 Lifecycle Automation

In VMware Cloud Foundation (VCF) 9.1, the platform offers flexible methods for programmatic access. We have already discussed the default mechanism: using a VIDB token to obtain a bearer access token for VCF component API access in the first blog VCF 9.1 API Access (1): Basic of this series. This blog post explores an advanced alternative: how to exchange an external IdP OIDC access token for an Identity Broker bearer access token.

The Default Path: VIDB Token Exchange

By default, VCF 9.1 supports using a VIDB token to exchange for an access token.

  • The Mechanism: The token is generated and signed directly by the Identity Broker.
  • The Benefit: This method significantly simplifies day-to-day operations by centralizing the signature process within the VCF platform.

IdP-Validated Access

While the default method is efficient, it is not always the desired approach for high-security environments. Some organizations require that every access token generation operation initiated by an SSO user be validated by their own external Identity Provider (IdP) before access is granted.

This ensures that the IdP remains the authoritative source for every session, allowing organizations to enforce real-time security policies, conditional access, and compliance checks.

To implement this level of control, users can utilize the following two-step exchange flow:

  1. Obtain an IdP OIDC Token: The user authenticates directly with their organization’s IdP (such as Okta or Microsoft Entra ID) to receive an OIDC access token.
  2. Exchange with the Identity Broker: The user exchanges this IdP-issued OIDC token with the VCF Identity Broker to receive the final VCF access token required for API operations.

⚠️ Security Note: The example below uses the Resource Owner Password Credentials (ROPC) grant type to quickly demonstrate how to retrieve an Okta OIDC token. For production high-security environments, it is strongly recommended to use more secure delegation flows, such as Authorization Code Flow with PKCE.

Step 1: Retrieve the Okta OIDC Token

Below is an example of retrieving an Okta OIDC access token using a password grant:

curl --request POST \
  --url https://{{okta-fqdn}}/oauth2/default/v1/token \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=password \
  --data 'username={{oktaUserName}}' \
  --data 'password={{oktaUserPassword}}' \
  --data 'scope=openid email profile groups' \
  --data 'client_id={{oktaClientId}}' \
  --data 'client_secret={{oktaClientSecret}}'

Response:

{
  "token_type": "Bearer",
  "expires_in": 3600,
  "access_token": "eyJraWQiOxxxxhie-S4XVHPSLWXzIPTOwdD0S_Yw",
  "scope": "openid groups email profile",
  "id_token": "eyJraxxxScFFHWTY5NyIsIm5hxxxTKftQz3o1iGjOJwugwEd3UBg"
}

Step 2: Exchange the OIDC Token for a VCF Access Token

Use the Okta Access token to get the VIDB access token.

curl --request POST \
  --url https://flt-idb01.rainpole.io/acs/t/CUSTOMER/token \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
  --data subject_token_type=urn:custom:vcf:params:oauth:token-type:idp_access_token:oidc \
  --data requested_token_type=urn:ietf:params:oauth:token-type:access-token \
  --data 'subject_token={{oktaAccessToken}}'

Whether your environment prioritizes operational simplicity with the default VIDB path or demands strict external governance with IdP-validated access, VCF 9.1 provides the architectural flexibility to support your security compliance goals.

Happy automating!