oauth2 provider client secret stored incorrectly

[jtcarnes]

Currently, the terraform provider causes an inconsistent client_secret when the backend generates it. This causes other resources that use that client secret to then fail to create because of inconsistent input data.

Terraform version: 2022.6.3
Authentik version: 2022.5.3

I believe it is an issue with the storage as running the system in trace mode shows the api return to be consistent, but for it not to be what was stored in tfstate. This would be either an issue when the secret is deserialized from json or when it is stored.

Example

A trivial example between connecting authentik with hashicorp vault:

resource "authentik_provider_oauth2" "vault" {
  name               = "vault"
  client_id          = "vault"
  signing_key        = "SomeEXISTINGKEy
  authorization_flow = "6c990535-adcf-4196-8b87-4ec8548c1b20"
  redirect_uris = [
    "http://localhost:8200/ui/vault/auth/oidc/oidc/callback",
    "http://localhost:8200/oidc/callback",
    "http://localhost:8250/oidc/callback",
  ]
}

resource "authentik_application" "vault" {
  name              = "Vault"
  slug              = "vault"
  protocol_provider = authentik_provider_oauth2.vault.id
}

resource "vault_jwt_auth_backend" "authentik" {
  type               = "oidc"
  path               = "oidc"
  description        = "out authentik backend"
  oidc_client_id     = authentik_provider_oauth2.vault.client_id
  oidc_client_secret = authentik_provider_oauth2.vault.client_secret
  oidc_discovery_url = "http://localhost:9000/application/o/${authentik_application.vault.slug}/"
  default_role       = "reader"
  tune {
    listing_visibility = "unauth"
  }
}

This will error with the following:

│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for vault_jwt_auth_backend.authentik to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/vault" produced an
│ invalid new value for .oidc_client_secret: inconsistent values for sensitive attribute.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵

However, running terraform in trace mode will show more detail:

{"pk":4,"name":"vault","authorization_flow":"6c990535-adcf-4196-8b87-4ec8548c1b20","property_mappings":[],"component":"ak-provider-oauth2-form","assigned_application_slug":"vault","assigned_application_name":"Vault","verbose_name":"OAuth2/OpenID Provider","verbose_name_plural":"OAuth2/OpenID Providers","meta_model_name":"authentik_providers_oauth2.oauth2provider","client_type":"confidential","client_id":"vault","client_secret":"QG`}7gW|M#%$Mu,$I;{RSF_M[7x\\4Ub1qORcx4xS[7?g9>=rRYuj=GK^,_!s0^QX+MSTL-GV#TX_D\\rg-UzESGE@wnGZw0c:UuxFvq|SYIZ0M)C}rg1HMjh&.urHN!sO","access_code_validity":"minutes=1","token_validity":"minutes=10","include_claims_in_id_token":true,"signing_key":"2478cf44-fa23-42c0-9370-a8fd12c61aeb","redirect_uris":"http://localhost:8200/ui/vault/auth/oidc/oidc/callback\nhttp://localhost:8200/oidc/callback\nhttp://localhost:8250/oidc/callback","sub_mode":"hashed_user_id","issuer_mode":"per_provider","verification_keys":[]}: timestamp=2022-07-04T00:29:13.502-0400
2022-07-04T00:29:13.503-0400 [INFO]  provider.terraform-provider-authentik_v2022.6.3: 2022/07/04 00:29:13 
GET /api/v3/providers/oauth2/4/ HTTP/1.1
Host: localhost:9000
User-Agent: authentik-terraform@2022.6.3
Accept: application/json
Authorization: Bearer cHMFTeCsS2T1lPyXcwaUELBqKutqyxOlfFueGs0i15EC3JXjDTHRqrBJrUFVM2l39KRjrCUcjvWRNQ8voDbz9in5KglzKrb0k5sZvdQzRN9uejSMBWTJWi8mvjWkJpAM
Accept-Encoding: gzip
: timestamp=2022-07-04T00:29:13.502-0400
2022-07-04T00:29:13.547-0400 [WARN]  Provider "provider[\"registry.terraform.io/goauthentik/authentik\"]" produced an unexpected new value for authentik_provider_oauth2.vault, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .client_secret: inconsistent values for sensitive attribute

So the client secret is detected drifting and this is indeed the case, inspecting the tfstate file I find:

            "client_secret": "QG`}7gW|M#%$Mu,$I;{RSF_M[7x\\4Ub1qORcx4xS[7?g9\u003e=rRYuj=GK^,_!s0^QX+MSTL-GV#TX_D\\rg-UzESGE@wnGZw0c:UuxFvq|SYIZ0M)C}rg1HMjh\u0026.urHN!sO",

For ease of comparison, the client_secret from the api response repeated here to make it easier to see:

"client_secret":"QG`}7gW|M#%$Mu,$I;{RSF_M[7x\\4Ub1qORcx4xS[7?g9>=rRYuj=GK^,_!s0^QX+MSTL-GV#TX_D\\rg-UzESGE@wnGZw0c:UuxFvq|SYIZ0M)C}rg1HMjh&.urHN!sO"

It appears it has incorrectly translated some of the characters into unicode when storing them that is causing issues.

[jtcarnes]

To provide additional information, even cutting out vault and just creating an oauth2 provider, multiple runs will show a diff in the client secret. This has a strong possibility to be in the storage step. It looks like it's getting properly de-serialized from the api, but that's different from whats stored in state.

eg:
between runs:

resource "authentik_provider_oauth2" "vault" {
  name        = "vault"
  client_id   = "vault"
}

when run twice will show a diff in the client secret