Pound signs ("#") in email addresses not handled correctly by the okta client package

[jsstrellix]

Describe the bug

Email addresses that have "#" in them (e.g. "my#email@foobar.com") may be uncommon but the "#" character is a valid email character (https://en.wikipedia.org/wiki/Email_address). The Okta client package should properly encode it (%23) when forming url's with it. However, it leaves it as "#", and consequently because it's a special character in url's the actual web request gets terminated right there.

The api's I've observed this behavior with are the ones that correspond to the /api/v1/users/ and /api/v1/users//groups. My guess is there are others that I haven't discovered yet too. I included the error response information for these two requests in the additional information section.

I wondered if the problem might've been fixed in a newer version of the client but given that I didn't find any other reports of this issue (open or closed) and having a "#" in your email address is apparently quite rare, I don't think upgrading would solve it.

Reproduction Steps?

Call https://{yourOktaDomain}/api/v1/users/test###@myemail.com or https://{yourOktaDomain}/api/v1/users/test###@myemail.com/groups

SDK Versions

System:
OS: Windows 10 10.0.19045
CPU: (8) x64 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
Memory: 32.31 GB / 63.89 GB
Binaries:
Node: 16.19.1 - C:\Program Files\nodejs\node.EXE
npm: 8.19.3 - C:\Program Files\nodejs\npm.CMD
Browsers:
Chrome: 112.0.5615.138
Edge: Spartan (44.19041.1266.0), Chromium (113.0.1774.35)
Internet Explorer: 11.0.19041.1566
npmPackages:
@okta/okta-sdk-nodejs: ^6.6.0 => 6.6.0

Additional Information

[OktaApiError: Okta HTTP 404 E0000007 Not found: Resource not found: test (User). ] {
status: 404,
errorCode: 'E0000007',
errorSummary: 'Not found: Resource not found: test (User)',
errorCauses: [],
errorLink: 'E0000007',
errorId: 'oaezLDplu3nSKivGU0o3zgxtQ',
url: 'https://{yourOktaDomain}/api/v1/users/test###@myemail.com',
headers: Headers {
[Symbol(map)]: [Object: null prototype] {
date: [Array],
server: [Array],
'content-type': [Array],
vary: [Array],
'x-okta-request-id': [Array],
'x-xss-protection': [Array],
p3p: [Array],
'content-security-policy': [Array],
'x-rate-limit-limit': [Array],
'x-rate-limit-remaining': [Array],
'x-rate-limit-reset': [Array],
'cache-control': [Array],
pragma: [Array],
expires: [Array],
'x-content-type-options': [Array],
'strict-transport-security': [Array],
'content-encoding': [Array],
'set-cookie': [Array],
connection: [Array],
'transfer-encoding': [Array]
}
}
}

[OktaApiError: Okta HTTP 404 E0000007 Not found: Resource not found: test (User). ] {
status: 404,
errorCode: 'E0000007',
errorSummary: 'Not found: Resource not found: test (User)',
errorCauses: [],
errorLink: 'E0000007',
errorId: 'oaennSdkcKhRQ-QZqYqkUbH4Q',
url: 'https://{yourOktaDomain}/api/v1/users/test###@myemail.com/groups',
headers: Headers {
[Symbol(map)]: [Object: null prototype] {
date: [Array],
server: [Array],
'content-type': [Array],
vary: [Array],
'x-okta-request-id': [Array],
'x-xss-protection': [Array],
p3p: [Array],
'content-security-policy': [Array],
'x-rate-limit-limit': [Array],
'x-rate-limit-remaining': [Array],
'x-rate-limit-reset': [Array],
'cache-control': [Array],
pragma: [Array],
expires: [Array],
'x-content-type-options': [Array],
'strict-transport-security': [Array],
'content-encoding': [Array],
'set-cookie': [Array],
connection: [Array],
'transfer-encoding': [Array]
}
}
}

[denysoblohin-okta]

Thanks for reporting this issue.
Internal ref: OKTA-609249
As a workaround can you use user id instead of email when constructing API requests?
We kindly ask you to migrate to @okta/okta-sdk-nodejs 7.0 if it's possible. It does not contain the fix for your issue yet, but v7 is generally more advanced.

[jsstrellix]

We don't have immediate plans to update our client but if we haven't by the time this bug is fixed, we'll certainly revisit at that point. Thanks!

[denysoblohin-okta]

The version 7.0.1 to be released contains a fix for this issue