Add Ability to Authenticate through a "Bring your own Token" Setup

[Pieeer1]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

I would like to add the ability to authenticate through bringing your own auth token. This would allow for the user_impersonation token to be utilized with cloud environments/gtihub actions/ado pipelines by doing the following: az login az account get-access-token Taking that token as input, setting to the environment variable, and using that to scaffold environments as a user. This would in my opinion be useful to have as creation of certain resources (tenants) requires the user_impersonation token.

One Potential Issue is the lack of refresh-ability with the token, as msal tokens traditionally last 60~ minutes. I think the benefits outweigh the negative in this case.

New or Affected Resource(s)

provider "azuread" {}

Potential Terraform Configuration

provider "azuread" {
    use_pre_existing_token = true
    pre_existing_token = "eyJ0e....." 
}

References

Tenant Creation Feature which would benefit from this-> https://github.com/hashicorp/terraform-provider-azuread/issues/1263 Scope Required as user_impersonation for CIAM tenants here -> https://learn.microsoft.com/en-us/rest/api/activedirectory/ciam-tenants/create?view=rest-activedirectory-2023-05-17-preview&tabs=HTTP

• 0000

[manicminer]

Hi @Pieeer1, thanks for suggesting this. Whilst I appreciate the potential utility here, we won't be adding the ability to provide a bare access token to the provider. There are multiple reasons that this does not scale and potentially causes more issues.

1. Access tokens are temporary, when they expire we need to get a new one. This is a hard requirement.
2. Access tokens are scoped, so we might need several different tokens for different APIs.
3. They do not provide enough information to configure the provider for all resources, or to maintain compatibility with existing configurations in the wild.

Instead, support for a desired authentication mechanism should be implemented in the provider and/or SDK. There are a number of objective and subjective criteria we try to apply when considering additional authentication methods, including but not limited to:

1. Does it have widespread use and therefore applicability to Terraform users?
2. Can we maintain consistent support for authentication and environment primitives, as we have with existing methods, across the provider?
3. Can we ensure continuity for long Terraform apply operations (several hours at a minimum)?
4. Is it straightforward to use / does it fit in with design principles of Terraform and/or the provider(s)?

So unfortunately we will not be able to add the ability to consume a bare access token, as it simply doesn't scale and will block future work in the provider.

From where do you plan to source access tokens? It may be that we can consider implementing direct support for a new authentication mechanism, subject to the above considerations.

Taking the above into account, I'm going to close this issue and the corresponding PR, but am happy to continue the discussion in this thread. Thanks!

[Pieeer1]

@manicminer That's entirely fair. The temporary lifetime of the tokens is an issue I noted above. This is really just an unfortunate scope issue with the user_impersonation scope being required for the tenant creation functionality. This requires user interaction obviously, so tenants IE https://github.com/hashicorp/terraform-provider-azuread/issues/1263 would not be able to function entirely.

The tokens would be sourced ideally from the az account get-access-token (same way this provider accesses them through the azure cli authorizer)

If this functionality is never implemented, and user_impersonation is not changed as the scope, 1263 becomes nigh impossible.

[manicminer]

Do you know a way to get a token from Azure CLI with the necessary scope(s)?

We have some preliminary ideas for improvement in this area, but if there's a way to shoehorn Azure CLI to provide a working token I'd be keen to look at that.

[Pieeer1]

I played around with that on another branch before realizing it was a larger change than I initially thought, as the way the scopes are attached to the environments are a little tough. Additionally, it requires user interaction to login using a user_impersonation scope. When you do a default az login and it opens a browser, that is the scope that you receive.

Unfortunately, I think the protections provided by the user_impersonation scope make this difficult to automate. Example:

This happens even though I am logged in with the user impersonation scope:

To add on, this does not verify the scope the az cli is logged in under. It is just the default for the cli when running locally.