Dex reports "invalid client_secret on token request", but it's a lie

[larsks]

Preflight Checklist

• [X] I agree to follow the Code of Conduct that this project adheres to.
• [X] I have searched the issue tracker for an issue that matches the one I want to file, without success.
• [X] I am not looking for support or already pursued the available support channels without success.

Version

sha256:da2d2c8f79a77442c90f8759304aaca73cecf5c0174142a6fd3a4a27dd0c3657 (that's latest as of 2024-11-20`)

Storage Type

In-memory

Installation Type

Official container image

Expected Behavior

I have configured minio to authenticate using dex (both running on openshift). The minio configuration looks like this:

MINIO_IDENTITY_OPENID_CONFIG_URL=https://dex-lars-sandbox.apps.example.org/.well-known/openid-configuration
MINIO_IDENTITY_OPENID_CLIENT_ID=minio
MINIO_IDENTITY_OPENID_CLIENT_SECRET=secret
MINIO_IDENTITY_OPENID_ROLE_POLICY=readwrite

MINIO_BROWSER_REDIRECT_URL=https://minio-console-lars-sandbox.example.org

The dex configuration looks like this:

issuer: https://dex-lars-sandbox.example.org

storage:
  type: memory

web:
  http: "0.0.0.0:5556"

grpc:
  addr: "0.0.0.0:5557"

telemetry:
  http: "0.0.0.0:5558"

oauth2:
  skipApprovalScreen: true

staticClients:
- id: minio
  redirectURIs:
  - 'https://minio-console-lars-sandbox.example.org/oauth_callback'
  - 'https://minio-console-lars-sandbox.example.org'
  name: 'MinIO'
  secret: $MINIO_IDENTITY_OPENID_CLIENT_SECRET

connectors:
  - type: openshift
    id: openshift
    name: OpenShift
    config:
      issuer: https://kubernetes.default.svc
      clientID: system:serviceaccount:lars-sandbox:dex
      clientSecret: $OPENSHIFT_CLIENT_SECRET
      redirectURI: https://dex-lars-sandbox.example.org/callback
      groups:
        - system:authenticated

logger:
  level: "debug"
  format: "text"

The value of MINIO_IDENTITY_OPENID_CLIENT_SECRET is correct inside the dex container:

$ k exec -it deploy/dex -- env | grep MINIO_IDENTITY
MINIO_IDENTITY_OPENID_CLIENT_SECRET=secret

OPENSHIFT_CLIENT_SECRET is also set correctly.

The client secret is presented correctly in the request to /token. Running a packet capture and then examining the request, we see:

POST /token HTTP/1.1
user-agent: Go-http-client/1.1
content-length: 158
authorization: Basic bWluaW86c2VjcmV0
content-type: application/x-www-form-urlencoded
x-forwarded-for: 173.48.196.116
host: dex-lars-sandbox.example.org
x-forwarded-host: dex-lars-sandbox.example.org
x-forwarded-port: 443
x-forwarded-proto: https
forwarded: for=10.30.6.108;host=dex-lars-sandbox.example.org;proto=https
x-forwarded-for: 10.30.6.108

code=ov2a2ptgdftc23h5f7qiflwy4&grant_type=authorization_code&redirect_uri=...

If you decode the authorization header, you will see:

$ echo bWluaW86c2VjcmV0 | base64 -d
minio:secret

The client id is correct, and the client secret is correct.

I expect this to result in a successful login.

Actual Behavior

Dex reports:

dex-5df78fbf99-g4f7z dex time=2024-11-20T21:38:10.139Z level=INFO msg="invalid client_secret on token request" client_id=minio request_id=6335c1e2-d7f2-487d-9331-8a63cf012d52
dex-5df78fbf99-g4f7z dex time=2024-11-20T21:38:10.141Z level=INFO msg="invalid client_secret on token request" client_id=minio request_id=0517bd1b-893b-4cb1-9551-d950c27d8439

Steps To Reproduce

No response

Additional Information

No response

Configuration

(included above)

Logs

time=2024-11-20T21:35:41.131Z level=INFO msg="Version info" dex_version=master go.version=go1.23.2 go.os=linux go.arch=amd64
time=2024-11-20T21:35:41.131Z level=INFO msg="config using log level" level=DEBUG
time=2024-11-20T21:35:41.132Z level=INFO msg="config issuer" issuer=https://dex-lars-sandbox.example.org
time=2024-11-20T21:35:41.132Z level=INFO msg="config storage" storage_type=memory
time=2024-11-20T21:35:41.132Z level=INFO msg="config static client" client_name=MinIO
time=2024-11-20T21:35:41.132Z level=INFO msg="config connector" connector_id=openshift
time=2024-11-20T21:35:41.132Z level=INFO msg="config skipping approval screen"
time=2024-11-20T21:35:41.132Z level=INFO msg="config refresh tokens rotation" enabled=true
time=2024-11-20T21:35:41.169Z level=INFO msg="keys expired, rotating"
time=2024-11-20T21:35:41.341Z level=INFO msg="keys rotated" next_rotation=2024-11-21T03:35:41.341Z
time=2024-11-20T21:35:41.341Z level=INFO msg="listening on" server=telemetry address=0.0.0.0:5558
time=2024-11-20T21:35:41.342Z level=INFO msg="listening on" server=http address=0.0.0.0:5556
time=2024-11-20T21:35:41.342Z level=INFO msg="listening on" server=grpc address=0.0.0.0:5557
time=2024-11-20T21:38:09.674Z level=INFO msg="login successful" connector_id=openshift username=larsks preferred_username=larsks email="larsks (unverified)" groups="[...]" request_id=5655d462-39df-422f-b274-e6b783dfdb20
time=2024-11-20T21:38:10.139Z level=INFO msg="invalid client_secret on token request" client_id=minio request_id=6335c1e2-d7f2-487d-9331-8a63cf012d52
time=2024-11-20T21:38:10.141Z level=INFO msg="invalid client_secret on token request" client_id=minio request_id=0517bd1b-893b-4cb1-9551-d950c27d8439

[torfjor]

Makes sense, because "$MINIO_IDENTITY_OPENID_CLIENT_SECRET" does not equal "secret".

Are you looking for the secretEnv key?

[cardoe]

@larsks your configuration should be using secretEnv to load your secret from an environment variable. You are using the string name with the $.

[larsks]

@cardoe Thanks, I think I figured that out. My recollection is that the documentation and examples were a little unclear on that point, but things have been working for a while. Thanks all!