Microsoft OAuth2 Credentials don't accept expressions / external secrets

[erictmnz]

Describe the problem/error/question

When we add Microsoft Oauth2 Credentials and use fixed, hard coded client id and secret then the connection succeeds.
However, when we use expressions and/or external secrets then the credentials saves but the Oauth flow can't be completed.

Note, that with Azure KeyVault the dot notation is still defunct as well.

What is the error message (if any)?

Debug info

core

• n8nVersion: 1.82.2
• platform: npm
• nodeJsVersion: 20.18.3
• database: postgres
• executionMode: regular
• concurrency: 3
• license: enterprise (production)

storage

• success: all
• error: all
• progress: false
• manual: true
• binaryMode: memory

pruning

• enabled: true
• maxAge: 4032 hours
• maxCount: 0 executions

client

• userAgent: mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/133.0.0.0 safari/537.36
• isTouchDevice: false

Generated at: 2025-03-13T00:05:58.431Z}

[Joffcom]

Hey @erictmnz,

We have created an internal ticket to look into this which we will be tracking as "GHC-1177"

[Joffcom]

Hey @erictmnz

What happens if you try a secret path that we support?

Looking at our docs we still only officially support a-z A-Z 0-9 and _ but it looks like you have a hyphen in your path.

[erictmnz]

Hi @Joffcom ,
Unfortunately some Azure products hyphenate keys (Azure Aspire for hierarchical secrets) and we can't do anything about that so using the dot notation or not using hyphens is not an option.

This is not causing any issues in the other ~25 credentials though - it's specifically this one that seems to not recognise it and perhaps it's not picking up expression vs fixed values in the fields. Because when the static value is entered as an expression it also fails.

[Joffcom]

Hey @erictmnz

Is it just that one credential or is it all oauth credentials? There was a similar issue in the past that impacted oauth credentials.

I would also be wary of using secrets that are not officially supported as well, while it may work in some cases it is not a valid path in our implementation so you may see issues in the future.

Quick edit: this is the PR that resolved this issue previously #13110

[erictmnz]

Hi @Joffcom,

I just tested it and it does seem to be an issue with other OAuth credentials as well.
Using the [""] notation workaround was the advice given by the n8n Enterprise team during our evaluation.
So it would be great to see hyphens supported in the dot notation or Oauth credentials to be updated to work with the [""] notation.

Thanks - appreciate linking the PR as well - looks like a similar issue.

[Joffcom]

Hey @erictmnz

Was it the sales team or support team that recommended this just so I know where to check in the morning 🙂

It looks like the PR is included in the version you are on so the question then will be... do we also fix this for something we don't support or do we wait until we do support it to resolve it.

For now the temporary option could be to try credential overwrites which would then hide the secret and client fields in the ui so you only need to worry about setting the scope.

Ignore that it mentions embed this works on all versions: https://docs.n8n.io/embed/configuration/#credential-overwrites

[erictmnz]

Hi @Joffcom,

We were working through this with Marcus and Liam who seem to have consulted with other colleagues in the background. :)
My preferred outcomes would be that hyphens are supported on Azure Key Vault since that also fixes the suboptimal experience of having to reformat the secrets to the [""] format.

The credential overwrite looks like a possible workaround that we could potentially run from our CI/CD pipeline - although it does slow down adding secrets and complicates the setup with the pipeline step so probably not preferred.
UPDATE: This might actually not be feasible since we will have multiple oauth2 accounts (eg for different Microsoft roles / apps) and if I understand the overwrite correctly, it would apply to all credentials of the same type.