I have configured a Group mapper for my Kong client. Unfortunately I see that when a user has no groups the group mapper returns an empty object instead of an empty array.
This breaks the JSON parsing on my hand (Kotlin server using jackson to automatically deserialize my data class, so the code for the parsing isn’t easily modified, moreover I really want to avoid workarounds for this kind of stuff… I use jackson/data classes because they automatically handle parsing, I just have to provide a type. If you switch type for the no-group case it forces all user to avoid using the goodies of modern languages and parse stuff manually).
I believe this is a bug right? When no groups are present either do not output anything (i.e. do not add the attribute to the token/user-info) or it should return an empty array not empty object!
If a Claim is not returned, that Claim Name SHOULD be omitted from the JSON object representing the Claims; it SHOULD NOT be present with a null or empty string value.
I don’t believe it is a bug. It is valid OIDC implementation, which was chosen by Keycloak devs. It will be bug if there is any OIDC/JWT spec, where it is defined as you are expecting.
What you quoted says the opposite of your conclusions. It says that you should omit such values.
Instead Keycloak does not omit it and instead uses an empty object.
What you wanted to say is this:
Keycloak devs actively decided to disregard the specs suggestion of ommitting such values
Moreover Keycloak devs decided to piss off any developer working with deserializing their data. There is no good reason to return an empty object for a claim that should be a list! The only reason is pure lazyness to handle the case I guess.
Yes it is permitted by the specs but this does not mean that it shouldn’t be considered a bug in Keycloak.
Moreover I cannot easily find any documentation about this behaviour, which probably means that there are plenty of bugged integrations around simply because you switch type from list to object in the empty case.
I would say that’s wrong assumption. It is not defined, so each IDP may have own opinionated implementation. It doesn’t mean that’s buggy implementation.
Did you try to blame devs of used SP? For me it looks like their pure lazyness, when they didn’t cover this kind of edge case.