Can n8n execute workflows for different users without adding them manually to the credentials list?
Eg: a user would connect his Asana account “Connect Asana” and then the workflow can grab everything and post them on his slack after he connected his slack account as well.
My main interest is the connectors n8n has which are very handy and hassle free and easy to use with minimal to no code
n8n can manage multiple connections to a single service (such as Asana), but users would typically have to log into n8n to perform the authentication (at least for OAuth2). Or in other words all users would also have to be n8n users.
Hello, is there a way to use n8n with different OAuth2.0 credentials (for different users, without adding them to n8n users) while using n8n cloud?
If i didn’t make any sense, here is an example:
A user would connect his account with my service, then i would pass his credentials to n8n and use the nodes and flows n8n has, with his credentials. Then repeat for a different user who connected his account as well…
That would theoretically be possible, but it would be some work. Currently, n8n takes care of everything and OAuth is literally the definition of “not fun”. You would have to write all of that yourself (obviously not all, as you could also use libraries). After you then collected that “information” you could use the API to create that credentials in n8n and use it like any other.
So that means i would need to host my own n8n instance (don’t wanna deal with that, the cloud is more appealing) and write a bunch of code so i can feed the necessary information to the nodes.
So currently, is there an option/way where i can feed n8n nodes (such as asana/slack…) custom tokens all in the cloud?
@jan Ok cool, i checked it out and seems this is the solution i need with 1 exception so far (google stuff).
So i want to pass a Google Drive OAuth2.0 token (and other needed information) to n8n which i acquired with my backend. But i can’t seem to find a way to do that programmatically.
{
"message": "request.body.data is not allowed to have the additional property \"token\",request.body.data requires property \"clientId\",request.body.data requires property \"clientSecret\",request.body.data requires property \"scope\""
}
So i have my clientId, clientSecret, and the scope. But how can i pass the rest of the information i acquired so i can use the n8n Google Driver node/connector?
Looks like an additional key has to get added to enable that. Currently the checking seems to be to strict and only supports the ones which are defined as parameter and not the ones that get dynamically added. Will be the same issue for all OAuth2 credentials. We will have a look at that.
Btw. this is how the data structure actually looks like:
And thanks for the great support, not gonna lie, n8n is a beast of a software, and yet with so much more potential to unlock. Adding a way to programmatically fine control auths would unlock so much more potential with n8n
Yeah, you guys created something extremely helpful and useful!
The oauthTokenData is what i meant by it. I recommend announcing this feature clearly in a “why choose n8n?” page, super cool
So to reiterate, and accept your next answer as a solution for this thread
In the next release, which is within a week or so, n8n will support a way to programmatically set OAuth data in credentials as well. N8n nodes will be able to use those oauth credentials.
{
"message": "request.body.data is not allowed to have the additional property \"authQueryParameters\""
}
if i omit that param, and i go play around in n8n, the credential i added programmatically works, but no idea if the param has any effect on the long run with n8n
is the param important or can i safely ignore it if i provided the refresh token?
where can i find a template/schema for each credential type to POST to create a credentials using the n8n api?
The parameter authQueryParameters is set to access_type=offline&prompt=consent in the googleOAuth2Api and can so not be overwritten. But do not think you have to overwrite it, simply omit it.
Regarding the schema, there is an API endpoint for that:
That lists the available properties and as mentioned above, does oauthTokenData simply expect whatever the OAuth callback received.