Align null claim handling in ID tokens with OIDC recommendations

[fullstackdesign-xyz]

Description

The OpenID Connect Core specification (Section 5.1) recommends omitting claims with null values from ID tokens. However, node-oidc-provider currently explicitly includes null claims in the ID token. This behaviour, while valid, may cause compatibility issues with strict OIDC client implementations and deviates from the specification's guidance.

👩🏻‍💻 Current behavior example

An ID token generated by node-oidc-provider may include null claims like so:

{
  "sub": "user123",
  "email": "user@example.com",
  "picture": null // 🚨 Issues
}

🚨 Issues

1. Compatibility challenges: Strict OIDC clients (e.g., openidconnect-rs) that adhere closely to the specification may reject tokens with null claims, leading to integration issues.
2. Increased payload size: Including null claims unnecessarily increases the size of the token payload.
3. Deviation from best practices: The current behaviour does not align with the OIDC recommendation to omit null claims, which could confuse developers expecting compliance.

💡 Proposal

To improve compatibility and adhere more closely to OIDC best practices, I suggest the following changes:

1. Default behavior change: Modify the library to omit null claims by default.
2. Configurable option: Introduce a configuration option to allow developers to choose whether null claims should be included in the ID token.

📜 Relevant OpenID Connect Core 1.0 specification

The OpenID Connect Core 1.0 specification states:
"Claims with null values SHOULD be omitted from the ID Token." - Source: OpenID Connect Core 1.0 Specification

[panva]

Hi @fullstackdesign-xyz

The module merely returns the claims returned from the account's claims() method. Don't return null there and the module won't include them in the ID Tokens.

[panva]

i.e. use undefined instead of null and the json serializer won't include them.

[fullstackdesign-xyz]

Got it! Undefined over null makes perfect sense for avoiding serialisation. Thanks for clarifying!