Integrate SSO credentials with node credentials

Questions
1

Hi everyone,
I’m currently using n8n with SSO authentication (SAML), and I have a question about integrating the credentials obtained via SSO with the credentials used by nodes—especially custom nodes.
My goal is to reuse the same token (or authentication context) that the user gets when authenticating into n8n via SSO, and use that token to authenticate requests made by my custom nodes. In other words, instead of configuring separate credentials for the nodes, I’d like the node to automatically use the SSO-based authentication token that was used to log into n8n.
Is there a supported way to:
Access the SSO (SAML) authentication token or user session token from within a custom node?
Map or propagate the n8n user’s authentication context to node executions?
Or otherwise integrate n8n’s SSO authentication with custom credential handling?
If this isn’t currently possible, I’d also appreciate guidance on recommended patterns or workarounds for aligning SSO authentication with custom node integrations.
Thanks in advance for any insights or pointers!

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 2.3.4
  • Database (default: SQLite): PostgreSQL
  • n8n EXECUTIONS_PROCESS setting (default: own, main): main
  • Running n8n via (Docker, npm, n8n cloud, desktop app): docker self hosted
  • Operating system: ubuntu
2

Hi @Eric_Hans

Short answer: no, this isn’t supported in n8n right now.

SSO (SAML) in n8n is only used to authenticate users into the UI. The SSO token or session is not exposed to workflows or custom nodes, and it can’t be reused for node authentication.

Because of that, nodes must always use their own credentials (API keys, OAuth, etc.) configured in n8n. This separation is intentional for security and execution consistency.

If you need user context, the usual workaround is to pass the user identity explicitly (like email or userId) to the workflow and let the external service handle authorization.

2 Likes
3

Thanks for the explanation, @tamy.santos!

For my use case, this workaround of explicitly passing the user identity (such as email or userId) works very well for what I need right now.

Appreciate the clarification!

1 Like
4

I’m really happy to hear this helped :blush:

5

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.