Hey everyone,
Our company provides SSO capabilities with JWT authorization tokens that we’d love to use with n8n but noticed that there were a few incompatibilities. I’ve created this a pull request that adds the following functions:
JWT Cookie Support
JWKS EC-signed Key Support
Broader Tenant ID Support
Potential JWT Auth Performance Improvement
Hoping this gets picked up as this will really help us manage our user’s instances by eliminating predefined basic auth credentials, and allow us to leverage JWT for SSO and enhanced user security (via Tenant/Claim checking).
Thanks for any and all feedback!
n8n-io:master ← Ian-Taggart:master
opened 11:55PM - 15 Feb 22 UTC
Hi there, first time doing any kind of pull-request/enhancement to existing soft… ware so please let me know what I can do better. Here are my list of changes:
1. JWT Cookie Support
I noticed that n8n supported JWT authorization tokens, but only if it's passed as a header. Depending on the OAuth service, some products pass the JWT token as a cookie so this would allow n8n to work with those products too. You can define the cookie name with the following environment variable:
`N8N_JWT_AUTH_COOKIE`
I've designed the code to allow either the Header name or Cookie name to be defined, but not both. Having both seems redundant in my opinion and probably not a valid use-case.
2. EC-signed JWT Tokens
I also noticed that n8n did not support EC-signed JWT tokens, which is increasingly becoming an industry standard. Including the "jwks-ec" module helps solve this issue. I've included code that sets the jwksClient to use the "jwks-rsa" module by default, or "jwks-ec" if EC-signed tokens are going to be used. You can tell n8n to use "jwks-ec" by setting the following environment variable to true:
`N8N_JWKS_USE_EC`
3. Updating isTenantAllowed Function
Originally, the isTenantAllowed function would return a blanket true if the `N8N_JWT_NAMESPACE`, `N8N_JWT_ALLOWED_TENANT_KEY`, and `N8N_JWT_ALLOWED_TENANT` were not all defined in some manner. This seemed restrictive since tokens might not be multi-tenant. By only checking if the Tenant Key and Tenant ID are defined, n8n can parse through the decoded Token looking for any key-value pair that the user wants to allow. For example, most companies will place a user's account name in the "sub" key of a token, which could be a useful intermediary for authenticated user management. If a namespace is defined, the function will act as normal.
4. JWT Authentication Performance Improvement
Finally, I think I've improved the performance of n8n when doing JWT token based authentication. I noticed that n8n seemed to take 3-4x longer to load when using tokens. I think this was because the jwksClient was making a call to my JWKS server to grab the signing keys for every operation (GET, POST, etc). Typically, the jwksClient will want to cache those keys so that it's not making repetitive calls to the JWKS server - but by defining the jwksClient variable inside the middleware layer, it would continually be re-created and the keys weren't cached so it would have to wait for the server. By moving the definition of the jwksClient outside of the authentication middleware layer, it remains persistent across all middleware operations, using those cached keys.
Regardless, if the maintainers of n8n decide that Updates 1, 2, and 3 are not something they'd like to support, I think option 4 should be heavily considered as a modification to n8n.
Please let me know if you have any questions. Thanks!
Jon
February 18, 2022, 10:27am
3
Hey @Ian_Taggart ,
Looks like a good feature change to me
Thanks for the feedback, @Jon ! Do you need anything else from me regarding the pull request? Thanks again!
Jon
February 18, 2022, 8:21pm
5
Hey @Ian_Taggart ,
Not yet, I just need to find a bit of time to review it properly.
1 Like
Thanks for the update, Jon! I’ll look out for any communication from you on here or Github incase you have any questions.
1 Like
