
User16548073300991554295 (Customer) asked a question.
From what I've read in the spec, the preferred_username claim is a string value, yet I have some examples where the preferred_username claim is multi-valued as an array. We had production issues due to treating it as a string value when it came in as an array. I would ascribe it to the library we're using, but jwt.io shows it as an array in the decoded payload. Can someone help me understand:
- How would one even interpret more one value of something called "preferred". Is it ranked?
- How does this happen (our client believes they haven't done anything different with these users)
- Claims like sub, iss, and aud are always going to be single string, so clearly there is a difference between single- and multi-value claims. Is this spelled out anywhere for Okta tokens?
Obviously, we have a fix for it by doing more stringent checking, but it seems like it shouldn't be an issue.
Thanks!
Reference:
5.1 (https://openid.net/specs/openid-connect-core-1_0.html*StandardClaims) "This value MAY be any valid JSON string including special characters such as @, /, or whitespace"

Looks like the reference link got mangled. The asterisk should be a hash sign.
preferred_username can be any value. it pass from okta and your system can work with it as your system want. what scenario needs multi-value?
Thanks for responding. I should have phrased it better. In this case, I don't want more than one value for preferred_username and don't even understand how it's happening since only some users have it. The actual values differ only in case (abc@host.com vs ABC@host.com). I'm an app developer so don't know anything about how Okta generates that token or what their admin sees. Their admin swears there's only one value. So I'd like to be able to tell them what they might have done to create two values so it can be fixed. Maybe even a screenshot from an Okta configuration screen that would help me understand what they are seeing would be good.