Independent ID Token/UserInfo claim release, encrypted ID tokens, and first-class logout context to enhance federated logout scenarios and allow privacy by design

Product Feedback
1

Feature:

Independent ID Token/UserInfo claim release, encrypted ID tokens, and first-class logout context to enhance federated logout scenarios and allow privacy by design.

Description:

Auth0 currently creates a privacy and architecture tension:

  1. Auth0 currently couples standard OIDC profile/email scope claims across the ID Token and UserInfo response, rather than allowing customers to independently control their release to each destination.
  2. Custom UserInfo claims are configured by adding them to the ID token.
  3. Auth0 does not currently expose standards-based ID-token encryption using the OIDC client metadata defined for encrypted ID-token responses.
  4. id_token_hint is RECOMMENDED for RP-Initiated Logout. The specification permits both GET and POST; when GET is used, the complete ID token is serialized into the query string.
  5. POST logout reduces query-string exposure but is not uniformly exposed across client libraries and does not provide a general Auth0 logout-Action extensibility surface.
  6. Auth0 continues to expand standards-based logout and federated logout capabilities, but advanced/custom chained logout still lacks a normalized customer extensibility model.
    The result is that customers can be forced into a trade-off between:
    • putting profile PII in an ID token that has protocol uses capable of exposing the token to URL logging or
    • not using Auth0 ID token/UserInfo for those claims.

Requested capabilities

1. Independent UserInfo claim configuration

Provide a first-class API such as:

api.userInfo.setCustomClaim(
  "https://example.com/department",
  event.user.app_metadata.department
);

independent from:

api.idToken.setCustomClaim(...);
api.accessToken.setCustomClaim(...);

Acceptance criteria:

  • a claim can be returned by /userinfo without being in the ID token;
  • a claim can be in the ID token without automatically being returned by UserInfo;
  • standard profile / email claims can be suppressed from the ID token while remaining available through UserInfo;
  • claim-release policy can be configured per Client/application;
  • existing behavior remains available for backward compatibility.

2. Support destination-specific OIDC claims

Support the OIDC claims parameter with distinct handling of:

{
  "userinfo": {
    "given_name": null,
    "family_name": null,
    "email": null
  },
  "id_token": {
    "auth_time": null,
    "acr": null
  }
}

This would align Auth0 with the claim-destination model already present in OIDC Core.

3. ID-token encryption

Support standards-based encrypted ID tokens using client metadata equivalent to:

  • id_token_encrypted_response_alg;
  • id_token_encrypted_response_enc.

This should be independent of Auth0’s existing JWE capability for API access tokens.
Encryption does not replace data minimization, but it provides an important confidentiality control where sensitive ID-token claims are unavoidable.

4. GET/POST logout parity in SDKs and platform behavior

Auth0 should ensure that:

  • all maintained SDKs provide a clear supported method to perform POST RP-Initiated Logout;
  • GET and POST parameters are normalized to the same internal logout context;
  • security and privacy guidance makes the query-string exposure difference explicit;
  • token-bearing values are redacted from Auth0-owned logging and diagnostics where applicable.

Example of the current asymmetry: the documented custom-social getLogoutUrl(params, callback) extensibility model exposes logout input through params.query; there is no equivalent normalized POST/body logout context exposed to the script.

5. First-class logout Action/extensibility context

Provide a logout trigger with a normalized event model, for example conceptually:

exports.onExecuteLogout = async (event, api) => {
  // validated logout context
};

The event should provide validated contextual information such as:

  • Client ID;
  • Auth0 session ID;
  • connection / upstream issuer;
  • requested post-logout redirect;
  • whether federated logout was requested;
  • safe server-side references to upstream logout/session context;
  • normalized values independent of whether GET or POST initiated the request.

Raw upstream tokens should not need to be exposed unless explicitly required.

6. Server-side federation logout context

For federated OIDC sessions, Auth0 should maintain sufficient server-side federation context to perform supported upstream logout without requiring the downstream application to transport upstream tokens. That context should also be available to controlled logout extensibility through safe server-side references.

Use-cases:

Security and business value

The requested features would provide:

  • stronger PII data minimization;
  • reduced token and URL-log exposure;
  • smaller ID tokens;
  • cleaner separation of authentication, profile and authorization concerns;
  • better alignment with OIDC’s independent claim destinations;
  • more robust privacy-by-design controls;
  • less dependency on framework-specific logout behavior;
  • safer federated logout extensibility;
  • reduced need for nested-token workarounds.