Support the newer OAuth authentication method when connecting to TPP using a username and password

[maelvls]

BUSINESS PROBLEM

As of TPP 22.2, the /vedsdk/authorize endpoint is only available to customers who will have asked the Venafi customer support for a special license key (see WebSDK Authorization Method involving API keys is only available with a License Key).

The function NewClient relies on /vedsdk/authorize when authenticating with a username and password. For example, the following will not work with 22.2 without the license key entered:

c, err := vcert.NewClient(&vcert.Config{
		ConnectorType: endpoint.ConnectorTypeTPP,
		BaseUrl:       os.Getenv("TPP_URL"),
		Credentials: &endpoint.Authentication{
			User:     os.Getenv("TPP_USER"),
			Password: os.Getenv("TPP_PASSWORD")},
		Zone: os.Getenv("TPP_ZONE"),
})

PROPOSED SOLUTION

I suppose that vcert should somehow start using the endpoint /vedauth/authorize/oauth ("OAuth method") instead of /vedsdk/authorize ("API key method") for authenticating with a username and password.

I realize that this is not be a backwards-compatible change, since the client ID and scope are needed with OAuth method, and were not needed with the "API key" method. Users will also need to associate the user to one of the applications in the API Application Integrations UI.

CURRENT ALTERNATIVES

As a workaround, it is possible to "force" vcert to use the correct /vedauth/authorize/oauth endpoint with the following:

c, _ := tpp.NewConnector("https://tpp.example.local", "\VED\Policy\Certs", false, nil)
auth := endpoint.Authentication{
		Scope:       "manage:certificates",
		ClientID:          "vcert-sdk",
		User:     os.Getenv("TPP_USER"),
		Password: os.Getenv("TPP_PASSWORD")},
})
resp, _ := c.GetRefreshToken(&auth)
auth.AccessToken = resp.Access_token
_ := c.Authenticate(auth)

[tr1ck3r]

@maelvls what you are suggesting seems counter to one of the main goals of the TPP token authentication feature. We're striving to eliminate the use of username/password for API-based integrations because a compromised username/password will almost always provide greater access than a compromised access token. Access tokens are limited to a specific subset of TPP API methods whereas username/password (at a minimum) allows someone to get an unlimited number of new token grants and access the TPP UI. And if the user is a non-local user it would likely allow access to other non-Venafi resources.

So for security reasons this is not an enhancement we are considering for VCert. Going forward, API-based integrations should be bootstrapped with an access token and a refresh token (the latter assuming the integration has logic for refreshing the token at regular intervals).