Support linking OIDC accounts, not just git provider accounts

[bpmct]

Background

Coder allows developers to link their git accounts to simplify git authentication in their workspace. When they git clone, Coder helps them authenticate with their provider or a template can even require that they authenticate in advance of creating their workspace:

On the server side, the admin configures this by providing OIDC credentials to the Coder server. The Coder server will store and rotate users' tokens on their behalf. You can read about this feature in our documentation

Vision

There are other cases where a workspace can benefit to being pre-authenticated to other providers. Both for runtime (e.g. artifactory token is injected into the workspace) and build-time (user authenticates with a Terraform provider with their OIDC token).

Instead of Coder having to support native integrations with each platform, Coder supports generic OIDC (just like for log in and git auth) and then the template can use the token for whatever it wants (provisioning resources, pre-authenticating a CLI, etc).

To avoid code duplication, we can extend our git auth code to support non-git providers. Coder templates will still magically authenticate git for git providers with GIT_ASKPASS.

Mock server config:

CODER_INTEGRATION_0_ID=primary-github
CODER_INTEGRATION_0_TYPE=github
CODER_INTEGRATION_0_CLIENT_ID=xxxxxx
CODER_INTEGRATION_0_CLIENT_SECRET=xxxxxxx
CODER_INTEGRATION_0_GIT_REGEX=github.com/orgname

CODER_INTEGRATION_1_ID=azure-key-vault
CODER_INTEGRATION_1_TYPE=oidc
CODER_INTEGRATION_1_DISPLAY_NAME="Azure Key Vault"
CODER_INTEGRATION_1_ICON="https://wiki.example.org/akv.svg"
CODER_INTEGRATION_1_REQUIRED=true
CODER_INTEGRATION_1_CLIENT_ID=xxxxxx
CODER_INTEGRATION_1_CLIENT_SECRET=xxxxxxx
CODER_INTEGRATION_1_SCOPES="https://vault.azure.net/user_impersonation"

Within the template:

data "coder_integration" "azure-key-vault" {
  id="azure-key-vault"
}

resource "coder_agent" {
   # 
  env {
    name = "AZ_TOKEN"
    value = data.coder_git_auth.token
  }
}

Why not request all of these scopes when the user authenticates to Coder?

Identify providers are typically managed via a different organization than developer tools so it's typically difficult or impossible for organizations to create a central token that Coder can use directly against a large amount of APIs. Some advanced organizations allow token exchanges, but that is still not common.

For example, Azure Active Directory (a common identity provider) can only request scopes from Microsoft's Graph API. There is no way current Coder wants to also request a token that works for authentication and Azure Key Vault, for example.

[matifali]

we could also create a new resource coder_variable which would be populated by these auth providers and can be consumed by coder_agent to set in the workspace as an environment variable.

This could allow us to modularize the auth methods as separate modules.

[kylecarbs]

This is almost done!

[matifali]

This is complete as per v2.3.0. You can now create any OIDC integration using

1. https://coder.com/docs/v2/latest/admin/external-auth
2. https://registry.terraform.io/providers/coder/coder/0.12.2/docs/data-sources/external_auth
3. https://coder.com/docs/v2/latest/cli/external-auth