N8n API Add functions for credentials

Feature Requests
1

Hello,

I would like to suggest adding some functions in the API in order to be able to manipulate more easily the crendetials
1°) updateCredentials - (By Name / By Id)

This function would allow to update the existing credentials in case of key or password rotation in the applications.

Use case:
RabbitMQ : credentials are managed by Hashicorp Vault, a key rotation is active, credentials expire after a certain time
In n8n, with the id or the name of the credentials we could update the login information directly.

Currently, there is no choice but to create a new credential, and delete the previous one.

2°) getAllCredentials

This function would allow to list all credentials, without returning confidential information. The purpose of this function would be to search for a credential in the database and to retrieve its id/name in order to update it.

Use case:
A credential needs to be updated. The API would allow to list the APIs. With this list, we could find the desired credential, retrieve its Id and use the previous API (updateCredential) to update it.

Currently, there is no way to get the ID of a credential
In fact, I also wonder about the usefulness of the delete credentials by Id function, if we can’t have an id in a programmed way. We absolutely need to know the Id in a “manual” way

Why these function : Nowadays, computer security is becoming more and more important. Many systems are starting to implement secret rotation mechanisms through applications such as Hashicorp Vault.

The implementation of these features would allow more flexibility for n8n nodes.

Thanks

2

I can see the public API was only merged in June this year - nicely done! I would like to add a use case for getAllCredentials AKA a GET /credentials endpoint.

I’m currently using n8n to integrate firefly-iii and grist-core. I did it using an n8n workflow, but I also made a grist widget that gives the user control over the integration (via the workflow itself and the n8n API). One of the widget’s functions will be to install the n8n workflow inside n8n, then invoke the workflow to configure firefly-iii webhooks via its API. This needs a firefly-iii API key and a Grist API key to work, and ideally I’d like these to be stored and configured in n8n, not the user’s Grist document or widget settings.

To install the workflow in a user-friendly way, the user needs to be able to select which credential to use for grist and firefly-iii via the widget. It would be nice to populate a dropdown using a new endpoint GET /credentials .

3

That would be very useful! Patch should be available through api.

Also a little more documentation would help. I used my chrome devtools to inspect a manually created credential to be able to identify what should i put on the “type” required field do create a new credential.

4

Merry Christmas. Here is a PR for a GET /credentials endpoint

4 Likes
5

@Jon @MutedJam @jan @RicardoE105 - please could you get someone to take a look at my PR?

6

Hey @johncant,

I will create an internal ticket for a review but typically core changes take longer to consider as it has potential to impact features we are planning to work on.

At the moment if your PR solves the issue you currently have you can make a custom image from it and use that until we have completed a review and decided if we will accept the PR.

I would also try to not tag a bunch of us in a reply as we already have notifications configured and can see what is happening :slight_smile:

1 Like
7

Hi @Jon - thanks a lot!

8

Hi @Jon - do you have any update?

I notice it’s been so long the base branch has changed quite a lot and there are now some conflicts.

Wondering whether it’s worth investing my time resolving them and getting the PR mergeable again. Normally when submitting PRs to an active project, the changes either get merged, or you get reasons as to why they can’t be merged. Very unexpected to see what looks like complete apathy towards this feature added by a member of the community.

Seems like there was some sort of approval gate for the CI to run - and no-one even approved that!

1 Like
9

Hey @johncant,

It looks like this has not been picked up yet there are a few API changes that need to be reviewed but it all comes down to the priority and availability for someone in that team to review it.

The approval for the CI process happens when we review it and I suspect we will get to this one it is just a case of when. Our PR process for core changes does need some work so that we can get through the backlog of requests there though as there a good chunk of things that could be useful.

10

Any updates on this Jon?

11

Hey @Josh_Sorenson,

I believe we may have made the choice to not include an option to get credentials as it may be a potential security risk but it depends on what data you are actually after and what the planned usage is.

Are you after a way to just get the names and ids for credentials or the credential data itself?

12

For my cases, it’s only to list type and name (or ID) of credentials and update, Not the value. (Get the value is a vulnerability. It’s not good)
It’s necessary if I want to automatise credentials rotations for exemple

Exemple for rabbitmq

  • Set a key rotation in Hasicorp Vault for RabbitMq
  • Get the new credentials from rabbitmq
  • List the credential called (for exemple) “RabbitMQ Account” or Get the credential by Id or Name
  • If the credential exist, get credential ID
  • With the credential ID, update “RabbitMQ account” credentials (It’s necessary to verify if we have the right to do this).

As keys rotation is a good pratice, many services like databases (Postgres, MariaDB, Mysql, etc), services (RabbitMQ, Kafka, etc) can do this with many vault like HCP Vault, or Cloud Vault (AWS, Azure, etc).

So, If it’s impossible to rotate credentials, nodes for this services are useless.

13

I understand not having a GET method for the value, but dismissing it solely as a security risk is disappointing to me. I can already retrieve the credential ID and modify the credential by updating the workflow via API.

What I can’t do is update a credential value. It’s fine if I can’t see it, but allowing me to update it would be helpful. Dropbox uses expiring keys, so we have to retrieve the key from a database in every workflow to embed it into the HTTP node dynamically. This adds API calls to our database each time a workflow runs. If we had the ability to update credential values, we could update the credential globally and move on, eliminating the need to call a database each time.

14

Hey @Josh_Sorenson,

The only bit dismissed was being able to actually get a credential, As mentioned it depends on what data you are actually after if you just want names and IDs then it could be possible although I am not handling the PR to add this so it will need to wait for prioritisation still and part of that will depend on how many users want it.

@Gsyltc what you are trying to do should be possible already using the External Vaults feature which will let you use an expression for the credential value so when you rotate the key in Hashicorp n8n will periodically sync the value and start using that.

15

Specific API Additions I’d Like to See

Key-rotation isn’t my primary use case for this. Automatically re-mapping credentials by name (i.e. same credentials name but different n8n instance w/ different credentials ids for each named credentials item) after importing a workflow (e.g. promoting from QA to Prod) is where it would help for me. It would be even better to have an API like PATCH /workflows/{id}?remap-credentials-to-matching-names=true, but I know that’s just crazy talk. BTW, I realize some of this is rehash of what others have already said, just in a different format.

  • GET /credentials/{id}
    • returns:
      {
     "id": "2fdA6QYLSpsNHzvz",
     "name": "MongoDB Account",
     "type": "MongoDB",
     "encryptedValue": "U2BlaFsdGVkX1+RkyBla6fk0NxmJpjJPubTb"
  }
    • Note: “type” is a required input for n8n API: POST /credentials
    • Note: “encryptedValue” in the response is optional. It would be essentially useless without access to the encryption key anyway, and access to the encryption key probably implies access to the raw data too so :person_shrugging:.
  • GET /credentials?type=mongoDB
    • returns all credentials items matching the specified type
  • GET /credentials
    • returns all credentials items (full name/id/type map)
  • PUT (or PATCH) / credentials/{id}
    • body (for value replacement):
      {
  "value": "{\"userid\":\"xyz\",\"password\":\"abc123\"}"
}
    • Note: API server code would encrypt and overwrite “value” to the DB column for the specified credentials {id} record, but mask the value from log messages. Assuming this would be no less secure than when the UI dialog/browser sends on the initial POST/create
  • PUT (or PATCH) / credentials/{id}
    • body (for rename):
      {
  "name": "MongoDB Account - old - 2024/08/28T14:19:22"
}

Partial Workaround using n8n /workflows API

For the “GET” part, to obtain a mapping between credentials ids and names…

  • create a workflow (or several) just to wrap references to credentials items
  • include one node in the wrapper workflow assigned to each credential
    • no flow/connections
  • assign a tag to the “wrapper” workflow(s) like “CredentialsWrapper”
  • use the n8n API GET /workflows/ to grab the wrapper workflow’s json
  • extract the credential name<–>id mappings from the json.
  • use the id<–>name mappings to create new credential objects and/or modify credentials assignments in existing workflows.
    Here are the nuts and bolts of it in a workflow fragment:

Data Structure

The credentials json object structure in workflow json makes it awkward to parse out the “credential type” since the type appears as the name of an element/attribute, instead of the value of a fixed-name element/attribute. For example:

"credentials": {
   "mongoDb": {
      "id": "5Dt0QMtgAbc123yc",
      "name": "MongoDB account"
   }
}

This “uniform across all types” structure would be more friendly:

"credentials": {
   "id": "5Dt0QMtgAbc123yc",
   "name": "MongoDB account"
   "type": "mongoDB"
}
1 Like
16

Hi,

I’m facing the same issue, and I found this topic is still in discussion. I’m wondering if we can provide the following 2 GET endpoints as follows:
endpoint#1: get all credentials basic info

GET /credentials

When it succeeds, return the following response:

{
    "data":[{
           "id": string,
           "name": string,
           "type": string,
           "createdAt": string,
           "updatedAt": string
    }]
}

endpoint#2: get a credential basic info

GET /credentials/{id}

When it succeeds, return the following response:

{
"id": string,
"name": string,
"type": string,
"createdAt": string,
"updatedAt": string
}

NOTE: these two APIs don’t expose sensitive data, and are equally visible from the console like, so there should be no security concerns around the information they expose:

image
image2390×508 33.6 KB

They are needed for two main reasons. First, to maintain consistent visibility at both the API and WebUI levels; and second, to capture creation and update timestamps, which help organizations determine the identity associated with each connection. Without these details, once credentials are created, it becomes difficult to trace which identity is in use, potentially creating security risks if a privileged connection is exploited without detection