The idea is:
Note that this is not the same as using OAuth to authenticate via a user, as this would allow a workflow to authenticate as itself without involvement of a user.
Adapting the summary from GitHub’s equivalent, “OpenID Connect (OIDC) allows your [n8n] workflows to access resources in your cloud provider, without having to store any credentials as long-lived [n8n] secrets.”
This could be used, for example, with all of the Google Cloud-related credentials, to authenticate as a Google Cloud Service Account, without having to store the service account’s private key in n8n. Similarly, this would enable custom APIs to authenticate n8n API calls from n8n workflows without storing any additional secrets.
GitHub has an article witha good summary of the mechanism and its benefits: About security hardening with OpenID Connect - GitHub Docs
For Google Cloud, OIDC credentials need to be exchanged for actual API credentials using the secure token service, see GitHub - google-github-actions/auth: A GitHub Action for authenticating to Google Cloud.
My use case:
- In a PostgreSQL node, authenticate with PostgreSQL running in GCP without storing credentials that could leak
- Authenticate with Google Cloud Storage without storing credentials that could leak
- Authenticate with a custom backend to make API calls without introducing another authentication mechanism and storing credentials that could leak
I think it would be beneficial to add this because:
Security hardening, no storing of secrets
Any resources to support this?
Are you willing to work on this?
Probably not. This seems like a fairly major feature, including exposing endpoints on any n8n server that wishes to enable this functionality, and managing signing keys.