Client has refresh_token, but go-autorest returns error on refresh

[Moeser]

See downstream issue at hashicorp/go-azure-helpers#22

The client is authenticating via cached azure cli credentials, which include the refresh token. On refresh, after an hour or so of runtime, the following error is returned: "Manually created ServicePrincipalToken does not contain secret material to retrieve a new access token". That error appears to be coming from the go-autorest library here:

go-autorest/autorest/adal/token.go

Line 173 in 91963f3

return fmt.Errorf("Manually created ServicePrincipalToken does not contain secret material to retrieve a new access token")

Is this a bug in go-autorest? Maybe that error should only be thrown if the refresh token is also not present?

Here's how the client is setting up the token:
https://github.com/hashicorp/go-azure-helpers/blob/e1c07bf7137ebb4c3ea824efa392ce8b2ecc7a63/authentication/auth_method_azure_cli_token.go#L71

[jhendrixMSFT]

Are you sure the refresh token is included? When I run the az command in obtainAuthorizationToken() no refresh token is returned.

[Moeser]

Interesting, on double checking that az command, I don't see the refreshtoken either. If the refreshtoken were pulled in from another source (such as reading az's accessTokens.json or something) would refreshing be successful?

[jhendrixMSFT]

As long as the grant type isn't authorization code then yes it should work. See

go-autorest/autorest/adal/token.go

Lines 812 to 823 in 91963f3

	if spt.inner.Token.RefreshToken != "" {
	v.Set("grant_type", OAuthGrantTypeRefreshToken)
	v.Set("refresh_token", spt.inner.Token.RefreshToken)
	// web apps must specify client_secret when refreshing tokens
	// see https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code#refreshing-the-access-tokens
	if spt.getGrantType() == OAuthGrantTypeAuthorizationCode {
	err := spt.inner.Secret.SetAuthenticationValues(spt, &v)
	if err != nil {
	return err
	}
	}
	} else {

[Moeser]

Thanks @jhendrixMSFT . Since this isn't looking like a bug in go-autorest, I'll close this issue out.