Failed to validate dpop error

[mm192010]

Hello,

Due to org network blocking, i had to deploy entire platform with port 443.
otdfctl works correctly: Can create attributes, Protect/unprotect files, No DPoP validation errors

but java code using the SDK does not. it gives error

level=WARN msg="failed to validate dpop" err="incorrect `htu` claim in DPoP JWT; received [https://platform.opentdf.company.com:443/policy.namespaces.NamespaceService/GetNamespace], but should match [[/policy.namespaces.NamespaceService/GetNamespace]]"

Current Configuration
Caddy (reverse proxy)

https://platform.example.com:443 {
  tls /certs/tls.crt /certs/tls.key

  reverse_proxy {
    to h2c://platform:8080
    transport http {
      versions h2c 2 1.1
    }

    header_up Host {host}
    header_up X-Forwarded-Host {host}
    header_up X-Forwarded-Proto https
    header_up X-Forwarded-Port 443
    header_up X-Forwarded-Uri {uri}
    header_up Forwarded "proto=https;host={host}"
  }
}

OpenTDF config (opentdf.yaml)

server:
  port: 8080

  auth:
    enabled: true
    enforceDPoP: false
    audience: "https://platform.example.com"
    issuer: https://keycloak.example.com/auth/realms/opentdf

Any clue/flag i need to set in code ?

    private SDK buildSdk() throws Exception {
        return SDKBuilder.newBuilder()
                .platformEndpoint(config.platformEndpoint)
                .clientSecret(config.clientId, config.clientSecret)
                .useInsecurePlaintextConnection(false)
                .sslFactory(config.sslFactory)
                .build();
    }

[marythought]

Hi @mm192010 , thanks for the detailed write-up — the configuration context is really helpful.

We dug into this and what's happening is the Java SDK sets the DPoP htu claim to the full URL per RFC 9449 — e.g., https://platform.opentdf.company.com/policy.namespaces.NamespaceService/GetNamespace. But on the server side, the ConnectRPC interceptor only has the bare procedure path (/policy.namespaces.NamespaceService/GetNamespace) in its allowed htu list, so the match fails.

otdfctl is working because the Go SDK and the server currently agree on using just the procedure path as htu, so the match succeeds. The Java SDK includes the full origin, which the server isn't yet set up to accept in this code path.

The server does have lookupOrigins logic that reconstructs full URLs by checking Origin/Grpcgateway-Origin/Grpcgateway-Referer headers, but that only helps for the KAS /kas/v2/rewrap gateway alias. For all other procedures (like your NamespaceService/GetNamespace call), it falls back to a set of public endpoint paths that won't match. So even adding an Origin header in your Caddy config wouldn't fully solve it.

We've filed #3216 to track fixes needed on both the server and SDK sides.

In the meantime, if you need an immediate workaround: if your Keycloak is not issuing tokens with the cnf claim (i.e., DPoP binding isn't enabled in Keycloak), then enforceDPoP: false (which you already have) should let requests through without DPoP validation. If Keycloak is binding DPoP to your tokens via the cnf claim, DPoP validation will still be attempted regardless of that flag, and you'd need to disable DPoP on the Keycloak side as well until we get the server fix in.

Thanks again for surfacing this — it's helping us close a real gap in our DPoP support for reverse-proxy deployments.