Support client secret generation for IDPortenClient

[larsore]

Hi,

I’d like to request support for client secret generation when creating an IDPortenClient, and optionally, automatic rotation of the secret, similar to the functionality implemented in azurerator.

The background for this issue is that we aim to utilize the generated secret to implement a user login mechanism which currently only supports authentication via client secret, not private key JWT.

Happy to provide more context or help with implementation if needed!

Thanks!

[tronghn]

Hello. My initial stance is that this isn't really a client authentication method that we want to support in Digdirator. The choice of authentication method introduces additional complexity in the form of a new field, which we would have to have introduce an additional policy (at least internally in our organization) to deny its use and as well as additional documentation to discourage its use in general.

Digdir recommends that clients requiring authentication use private_key_jwt: https://docs.digdir.no/docs/idporten/oidc/oidc_api_admin.html#bruk-av-asymmetrisk-n%C3%B8kkel

This is in line with RFC 9700: Best Current Practice for OAuth 2.0 Security, section 2.5:

It is RECOMMENDED to use asymmetric cryptography for client authentication, such as mutual TLS for OAuth 2.0 [RFC8705] or signed JWTs ("Private Key JWT") in accordance with [RFC7521] and [RFC7523]. The latter is defined in [OpenID.Core] as the client authentication method private_key_jwt).

In our experience, most client implementations should support the private_key_jwt authentication method, at least for enterprisy software.

Could you elaborate on the client implementation? Is there a specific library or off-the-shelf software in use here, and is there no way to convince the maintainers of these to add support for the private_key_jwt method?

[larsore]

Thanks for the detailed response.

The plan on our end is to make use of the Envoy OAuth2 proxy protocol, which—as far as I’m aware—currently only supports client authentication via token_secret / client_secret. Unfortunately, it doesn’t yet support private_key_jwt, which limits our options.

Given that constraint, our request is primarily about enabling integration with this specific setup. We’re aware of the broader recommendations and fully understand the preference for private_key_jwt in terms of security best practices. Ideally, we’d prefer that method too, but until support is added upstream in Envoy, we’re a bit stuck.

That said, we understand your position and appreciate the clarity. If there’s any flexibility or suggestions for workaround (e.g., using Digdirator in a way that doesn’t violate internal policy but still enables this), we’re definitely open to ideas.

Thanks again!

[tronghn]

We'd suggest that you also submit a request to the Envoy project to add support for the private_key_jwt authentication method if there isn't one already. If there really is no other way then we'd be open to consider contributions that adds support for choosing authentication methods per client in Digdirator.

That aside, we've also noticed that Envoy's implementation doesn't appear to be fully compliant with OIDC and ID-porten's requirements. Notably:

• missing support for the front-channel logout spec (https://docs.digdir.no/docs/idporten/oidc/oidc_func_sso.html#single-logout-slo)
• missing validation of id_tokens as per OIDC Core 3.1.3.7
• no use of the nonce parameter for the initial invocation of /authorize

Have you performed the verification tests for ID-porten with the Envoy proxy?

[mahic]

Thanks for the thorough feedback on this @tronghn
You are right wrt OIDC-compliance in Envoy. There are issues registered in the Envoy repo regarding this, however progress seems to be quite slow.

Feature request submitted specifically for private_key_jwt: envoyproxy/envoy#40127

[larsore]

Would you be open to adding support for client secret generation behind a feature flag @tronghn ?
Happy to put together a PR if you’re good with it.

[tronghn]

Hey there. Apologies for the late reply. We’re glad to see that you want to contribute, but our stance is still that this feature isn’t a something we’d use ourselves nor recommend that others use when compared to private_key_jwt.

While we could add this behind a feature toggle in the controller itself, the field to choose authentication method would still have to be added as part of the CRD. We then have to consider things like restricting its usage for our own cases, the correct behaviour if a client decides to attempt to change their authentication method, and so on. There’s also the issue of ensuring that the client secrets are rotated before expiry. Most importantly, we currently don’t have the capacity to verify nor fix any issues related to the feature.

I think the best course of action for now is that you create and run your own fork of Digdirator with your desired changes. If you find that this is a feature that others would also benefit from, we’d welcome a pull request if you want to upstream your changes. I'll leave the issue open for now.