OpenID Connect realm should support more client authentication methods

[jkakavas]

Client Authentication methods are used by OICD Clients to authenticate to the Authorization Server when using the Token Endpoint. We currently support only client_secret_basic

See https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

[elasticmachine]

Pinging @elastic/es-security (:Security/Authentication)

[saragri31]

Hi,
Regarding authorization_code flow, support of client_secret_post would be useful as it's still used by many OPs (including ours). client_secret_jwt and private_key_jwt would be nice to have.

Support of PKCE flow (Authorization Code flow extension) would be also a great asset as it's more secure and now widely recommended.
See https://tools.ietf.org/html/rfc7636

[jkakavas]

Support of PKCE flow (Authorization Code flow extension) would be also a great asset as it's more secure and now widely recommended.

Thank you for the feedback @saragri31, PKCE is designed to help public clients ( i.e. RPs that are not able to securely store a client id and client secret ). In the elastic stack case, client_id is stored in the elasticsearch.yml and client_secret is stored in the keystore so in my opinion there is no reason at this moment to support PKCE.

[saragri31]

Hi @jkakavas
Thanks for your precision.
I didn't notice PKCE is designed for Native Mobile App, I was just thinking using this flow could be easier as you don't have to deal with client_id nor client_secret.
Indeed, within Elastic stack it's not something mandatory at the moment.
Regards

[mirkenstein]

Hi @jkakavas are there any plans on supporting PKCE authorization flow?

[jkakavas]

We would like to support PKCE for the authorization code flow eventually but since in openid connect and for non public clients this offers little additional security value, it is not currently high in our roadmap.

You can subscribe to this thread and we'll make sure to update it when we start working on it. cc @bytebilly

[jkakavas]

We have added support for "client_secret_post", "client_secret_jwt" in #58708. As such, only private_key_jwt is missing and we haven't received any requests to implement this so far. I will close this issue now and we can track the need for adding support for private_key_jwt in a separate issue if need be.