I have successfully configured an identity provider allowing my Keycloak clients to connect through our Azure AD.
I did this with the usual client id/secret pair, but while doing so I saw on the AAD UI that you could add certificates along secrets, and although the possibility of not needing to refresh the secret every few months is very pleasant, I find nothing on Keycloak that would help me achieve that.
So… Do you know if it is possible to use certificates instead of secrets to configure an AAD IdP on Keycloak ?
For the record, I tried using the “JWT signed with private key” value for the “Client authentication” option of my IdP.
I added the corresponding RSA certificate of my keycloak realm to my AAD App Registration, but got the following error (server log) when trying to authenticate as any user :
AADSTS700027: The certificate with identifier used to sign the client assertion is not registered on application. [Reason - The key was not found., Please visit the Azure Portal, Graph Explorer or directly use MS Graph to see configured keys for app Id ‘4cf948df-417b-4fc6-8d32-0ea54e6a51c8’. Review the documentation at [URL] to determine the corresponding service endpoint and [URL] to build a query request URL, such as ‘[URL]’]
I tried different settings/certificates but I never managed to go further than that…
The absence of reply makes me wonder…
If no one else is asking this question, and if there is no possibilty to achieve this (using certificates instead of secret strings), does it mean the secret strings are best practices ? Or is it because it is too complex to implement ?
Client secrets are considered less secure than certificate credentials. Application developers sometimes use client secrets during local app development because of their ease of use. However, you should use certificate credentials for any of your applications that are running in production.
On the other hand, when creating a secret within the Azure portal, it’s said a little differently:
For greater security, it is recommended that a certificate (rather than a client secret) be used as a credential.
It would be nice to have the option at least, for customers that may read the same guide.
I also have the same error trying to configure “JWT signed with private key”. Any update about it?
AADSTS700027: The certificate with identifier used to sign the client assertion is not registered on application. [Reason - The key was not found., Please visit the Azure Portal, Graph Explorer or directly use MS Graph to see configured keys for app Id ‘4cf948df-417b-4fc6-8d32-0ea54e6a51c8’. Review the documentation at [URL] to determine the corresponding service endpoint and [URL] to build a query request URL, such as ‘[URL]’]
I have the same problem. From what I understand (which is very little), the problem is that Keycloak sends its client assertion using a kid claim, while Azure expects the certificate to be identified using the x5t claim (see this thread).
Decoding my client_assertion sent by keycloak (printed when logging debug info) I get this header:
{
"alg": "RS256",
"typ": "JWT",
"kid": "<contains kid value from RS256 Realm certificate, probably not sensitive but censored anyway>"
}
What keycloak should send for Azure AD is this:
{
"alg": "RS256",
"typ": "JWT",
"x5t": "<base64-encoded SHA1 hash of the realm certificate, as shown in Azure AD certificate config>"
}
I have no idea if there is either a way to convince Azure AD to accept kid, or Keycloak to send x5t.
Not sure how often these discussions are picked up by contributors. However, I came to the same conclusion awhile back when I was playing around with this. It would be great to maybe create a direct AzureAD provider or update the Microsoft provider. While I understand that the OpenIDConnect should work, due to Microsoft difference of opinion on the claims used, that specificity could be baked into the specific provider.
