Streamlining SSO: Using JWT Claims Instead of Userinfo Calls in OIDC
Moving n8n's SSO flow to rely on JWT claims rather than a subsequent userinfo endpoint can simplify authentication, reduce latency, and enable attribute substitution for accounts that lack provider-side fields. The change is small technically but offers meaningful operational benefits for automation platforms and enterprises integrating multiple identity providers.
The proposed change to allow OIDC-based SSO flows to use JWT claims in place of an extra userinfo HTTP call reflects a pragmatic optimization with operational advantages. Once an ID token is received and verified, it often already contains the required claims (name, email, roles, custom attributes). Eliminating the additional request reduces a network hop, reduces failure modes tied to provider userinfo availability, and simplifies handling of attribute mapping across heterogeneous identity providers.
From an engineering perspective, the trade-offs are straightforward: ensure robust JWT validation (issuer, audience, exp, signature), support standard and custom claim namespaces, and provide configuration options for administrators to choose JWT-based vs. userinfo-based flows. Security considerations include proper handling of token lifetime and refresh flows, and guarding against overreliance on mutable claims that providers might not guarantee. Operationally, the feature enables substitution or augmentation of attributes by the relying party - for example, injecting a corporate identifier or fallback email when the provider omits one.
For businesses running automation platforms or multi-tenant services, switching to JWT-claims-first SSO reduces login latency and simplifies failure handling in distributed systems. It also lowers the operational coupling to identity provider availability and can make SSO interoperable with providers that intentionally limit userinfo endpoints. However, leaders must ensure their identity governance policies accept the model and that auditing/logging captures any attribute substitution for compliance.
Recommended actions: update SSO policy docs to reflect claim-sourced attributes, add configuration toggles and validation tooling in admin UIs, and run a staged rollout with monitoring for mismapped attributes. Integrate claims-based logging and alerts to detect drift between provider userinfo and token content so you can revert or refine mappings quickly.
Original Source
n8n Community