Azure-docs: client_secret - URI encoding does not work

[atkinchris]

Encoding client secrets causes invalid client errors

Description

Client secrets issued from the Azure Portal are generated with special characters which are not URI safe. Using a secret with any of these characters will cause an invalid_client error.

This has been reported before, on a few issues that have been subsequently closed - including one that was "resolved" by removing special characters from the generation pool, https://github.com/MicrosoftDocs/azure-docs/issues/30467 (which is not the case for Azure AD application secrets).

_Note:_ This error does not affect Postman, but does appear when making programmatic token requests.

Documentation Reference

In the docs for client credentials flow, client_secret is supposed to be URI encoded when requesting a token.

The client secret that you generated for your app in the app registration portal. The client secret must be URL-encoded before being sent.

However, this does not work. If a working secret is URI encoded, and used in a request, it will no longer work, producing an invalid_client error. Encoding a non-working secret, with special characters, produces the same result.

Suggestions

I would suggest that either:

• the /tokenendpoint gets support for URI encoded secrets, as per the documentation, or
• secrets are only ever generated from URI safe characters, and the documentation instructing them to be URI encoded be removed

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: e9e02a6a-cd93-700d-0073-cca2f6166d67
• Version Independent ID: 215511e6-6599-4aac-5592-635640a635cb
• Content: Use Microsoft identity platform to access secure resources without user interaction
• Content Source: articles/active-directory/develop/v2-oauth2-client-creds-grant-flow.md
• Service: active-directory
• Sub-service: develop
• GitHub Login: @rwike77
• Microsoft Alias: ryanwi

[Karishma-Tiwari-MSFT]

Thanks for the feedback! We are currently investigating and will update you shortly.

[shashishailaj]

@rwike77 Could you please review this and update the documentation as required.

Thank you.

[rwike77]

@hpsin, can you take a look at this one? Thanks.

[hpsin]

@atkinchris - do you happen to have one of these bad secrets? Apologies it took a while to reach out. Agreed on your two points - will reach out internally to see what the situation is with /token.

[atkinchris]

@hpsin - these are two of the secrets that did not work (they've been subsequently invalidated):

KWs:1u/S+DrH[lw9fWEgxCIgwxgk1Xx9
xcD359g+_JvmSSIjWlXn[Ph?Y5CfbkKV

[hpsin]

Thanks Chris, I appreciate it. We've opened up an internal item to change the set of applicable characters to just a-zA-Z0-9 so that there's no concerns around URI encoding any longer. We had an earlier item that shipped about a month ago that stripped inadvertent control characters from the secrets (which broke console apps), and your secrets help confirm that the issue still repros after that fix.

[atkinchris]

Great, thanks - is there a way to track the progress of this, for future readers?

Once this is complete, and secrets are issued only within a [A-z0-9] set, will URI encoding be removed from the docs for the /token endpoint?

[hpsin]

Not at this time. We'll close this issue and have a release note when the change goes out.

We won't remove URI encoding from the endpoint or the docs, however, for two reasons:

1. It's part of the standard, so we have to support it
2. Service principals can be created on the fly and given custom secrets that we can't control, so we have to support them.

[atkinchris]

Not at this time. We'll close this issue and have a release note when the change goes out.

OK, understood.

so we have to support them.

The endpoint didn't appear to URI decode secrets though - passing encoded secrets containing bad characters (even though they were encoded), did not work.

The docs saying that secrets should be URI encoded only added to the confusion - it suggests that the endpoint should be able to accept unsafe characters provided they're encoded, which was not true.

[rwike77]

@atkinchris, sorry for the slow reply. I just ran through the steps in this article and am not able to repro the URL decoding issue. I used a secret generated in the Azure portal, which had some special characters in it. I'd say the issue has been resolved by now. I was able to generate an invalid_client error by putting a URL encoded secret into Postman. Postman expects the secret to be in plain text, however, and encodes the parameter value for you. Did you perhaps do something similar earlier? @hpsin fyi.

[rwike77]

@atkinchris, hopefully your issue has been addressed. I'm closing this, feel free to re-open if you need to. #please-close