Escaping client secret in token request basic authentication header

[immsb1138]

I've recently been working with an application using AccessTokenManagement for acquiring a client credentials token. A specific Client Secret value that I have been testing with happens to contain a RFC 2396 reserved character (in this case the @ character). It appears that the character in the Client Secret is being escaped before being Base64 encoded to the Basic authentication value in the token request. I believe the escaping is occurring in the BasicAuthenticationOAuthHeaderValue class:

    /// <summary>
    /// Encodes the credential.
    /// </summary>
    /// <param name="userName">Name of the user.</param>
    /// <param name="password">The password.</param>
    /// <returns></returns>
    /// <exception cref="ArgumentNullException">userName</exception>
    public static string EncodeCredential(string userName, string password)
    {
        if (string.IsNullOrWhiteSpace(userName))
        {
            throw new ArgumentNullException(nameof(userName));
        }

        if (password == null)
        {
            password = "";
        }

        var encoding = Encoding.UTF8;
        var credential = $"{UrlEncode(userName)}:{UrlEncode(password)}";

        return Convert.ToBase64String(encoding.GetBytes(credential));
    }

    private static string UrlEncode(string value)
    {
        if (string.IsNullOrEmpty(value))
        {
            return string.Empty;
        }

        return Uri.EscapeDataString(value).Replace("%20", "+");
    }

In my case the OAuth token server is failing to provide a token because the Client Secret value with the escaped character is not seen as valid.

I'm curious why the ClientId and Client Secret values are being Uri escaped in this code before being Base64 encoded. I don't see that this is required by the RFCs that I've reviewed for OAuth or Basic authentication.

[AndersAbel]

OAuth 2.0 has its own special flavour of basic authentication where the user name and password should be encoded using the "application/x-www-form-urlencoded" algorithm. You are not the first (and surely not the last) to discover this quirk.

See RFC6749 section 2.3.1 for refence.

[immsb1138]

Awesome, thank you. That's exactly what I failed to find :-)
I will complain to the owner of the token server.