Access saved credentials from "expressions"

Hello, any news on this feature? I’m testing out n8n and I love it, but sometimes I need to use code in between nodes which also make use of access tokens / oauth2 to validate the api calls.

1 Like

I agree that the ability to input and save credentials (perhaps to local browser storage) would be very helpful. Consider the use case where an HTTP request requires an Oath2 Resource Owner Password Credentials Grant Type. This is not currently supported with normal Oath2 credentials, so I have to authenticate with a regular HTTP request. If I export the workflow JSON, the unencrypted credentials are visible.

The only way I can think of to make this work currently is to use something like Bubble to gather the credentials and pass those over a webhook to start the n8n workflow. I’m not sure I want to go there.

Here’s an example of code from Postman:

curl -X POST
https://<yoursubdomain.xyz.com>/oauth2/token
-F client_id=<your_client_id>
-F client_secret=<your_client_secret>
-F grant_type=password
-F scope=api
-F username=<your_username>
-F password=<your_password>

Response:

{
“access_token”: “ghi567faxxxxxxfb3adef9492def4bb83f8cd266”,
“expires_in”: 3600,
“token_type”: “Bearer”,
“scope”: “api”,
“refresh_token”:“7dbabca33def3fa0473cxxxxxxeb8feghi407a5b”
}

I think this would add superpowers to n8n. First, you get from the ability to make any arbitrary API calls to any authenticated service - if you need anything beyond what the default “module” provides.

But beyond that, consider - for instance - this use case: using a saved Google Drive OAuth credential to create an arbitrary authenticated API call to the Drive API which - for whatever reason - is currently not part the default module.

Now, because I need this API as part of the flow I can’t use n8n at all for my workflow since that would fragment my setup so I need to basically develop the entire flow from scratch. Even the parts that do have a dedicated module.

Welcome to the community @roses ! Thanks a lot for your input!

We are currently working on something that will allow users to use existing node credentials (like Google Drive OAuth2) and make custom requests.

6 Likes

Is there a PR/branch for this?

No, not yet. The most backend code is already in n8n, what is still missing is the frontend part. Is however already designed and we will start with implementing it soon.

2 Likes

Hello just adding another use case for this which is calling the n8n rest api (with user management enabled). Current workarounds for this all have the password saved in clear text e.g. How to authenticate for REST API with Users management activated?

This is def needed to eliminate clear text in many use cases the default credentials are not flexible enough for many REST APIs that need to have creds sent in the body

Hi @joeldeteves, have you checked out some of the latest releases? @RicardoE105 added that to the 0.199.0 release, there is now a toggle between sending credentials in the header or body for Oauth2.
I don’t know if that fix/update is affecting other default nodes with credentials in general but it certainly worked well for my own workflows using the generic Oauth2 credentials.

Cheers and thanks Ricardo!

2 Likes

Awesome! This is exactly what I was looking for. I didn’t see it because I was using the Microsoft Ouath2 API - wonder if this will get added to the other Oauth2 creds eventually because it would be useful to have it there. cc @RicardoE105 for visibility

PS - I can use this with Microsoft as well so that makes it a little redundant for my use case :slight_smile:

But if “Microsoft Oauth2” is just a generic one labelled “Microsoft” for organizational purposes, it makes sense to add this as an option there.

Adding to this @RicardoE105 not only would accessing saved credentials be useful for adding via an expression to any field (something that comes up frequently when dealing with tokens) but it would be nice to have a Generic Credential type that lets you add as many encrypted fields as you want, with or withour usernames - you would then be able to call those using an expression in the node

IMHO that would offer a lot of flexibility and solve a big problem, not sure how feasible this is

2 Likes

What do you mean with add it to other OAuth2 creds? All OAuth2 credentials should have this.

In the Microsoft Oauth2 credential there is no option to send in the body.

However that is okay because we can use a generic Oauth2 node instead.

Using credentials in expressions would be great. I work mostly on telegram bots using n8n - sometimes I use features not included in n8n telegram node like copying message or dynamically creating reply keyboard (depending on user data). Because of that I need to store the credentials in secure way on my prod machine (stored as an env variable in the container). I would be really nice feature to use credentials in the expressions.

1 Like

It does not need to because we add it behind the scenes. Each service works with either header or body but not both, so it does not make sense to have them pick which one to use when we know what the service uses (See in the MicrosoftOAuth2Api credential type below how we set it to the body for all Microsoft services). The generic one is different because we do not know the service you want to connect to; hence we cannot set the field for you.

import { ICredentialType, INodeProperties } from 'n8n-workflow';

export class MicrosoftOAuth2Api implements ICredentialType {
	name = 'microsoftOAuth2Api';
	extends = ['oAuth2Api'];
	icon = 'file:Microsoft.svg';
	displayName = 'Microsoft OAuth2 API';
	documentationUrl = 'microsoft';
	properties: INodeProperties[] = [
		{
			displayName: 'Grant Type',
			name: 'grantType',
			type: 'hidden',
			default: 'authorizationCode',
		},
		//info about the tenantID
		//https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols#endpoints
		{
			displayName: 'Authorization URL',
			name: 'authUrl',
			type: 'string',
			default: 'https://login.microsoftonline.com/common/oauth2/v2.0/authorize',
		},
		{
			displayName: 'Access Token URL',
			name: 'accessTokenUrl',
			type: 'string',
			default: 'https://login.microsoftonline.com/common/oauth2/v2.0/token',
		},
		{
			displayName: 'Auth URI Query Parameters',
			name: 'authQueryParameters',
			type: 'hidden',
			default: 'response_mode=query',
		},
		{
			displayName: 'Authentication',
			name: 'authentication',
			type: 'hidden',
			default: 'body',
		},
	];
}

Thanks that makes sense - but there are cases in Microsoft where we sometimes need to choose between sending in the header or the body, such as when requesting an Auth token. I will go back and test again, but I just wanted to share that with you.

EDIT: @RicardoE105 I’d like to add to this: We should be able to specify custom Body parameters in the credentials, not just the http request.

Here is a perfect example of something I can’t do right now using either the Microsoft credential or the Generic Oauth2 credential:

The Refresh Token in this case should not be stored in the node in plain text, but there is no way for me to specify it in the Body of the Oauth2 credential.

In addition, the grant_type can not be specified in the Oauth2 credential either.

So my suggestion / request is to allow adding of additional, masked+encrypted “body” parameters in the Generic Oauth2 creds.

1 Like

Hey @RicardoE105, Following this message from Nov 22. We are running n8n 0.203.1, however we do not see the option to pass the credentials in the body.
Can you explain how to do that?

Yes, but not straightforward.

  1. Create HTTP Request node to localhost with required credentials (set Continue on fail)
  2. in next nodes just read credentials from this node’s error response

@jan what would be a secure way to make API calls in the JavaScript node without exposing API Keys?

We tend to utilize the JS node when we run into limitations with the HTTP Node, but this results in API Keys being exposed in the workflow or execution history.

Hey @Eden,

The quickest option would be to not enable workflow logging for those flows.

Do you have an example of the limitations you are seeing with the http request node?