n8n authentication

Nodes platformin8nauthenticates with an OAuth 2.0 access token created in the platform’s user interface and stored in an8ncredential.

Each platform application includes:

Authorization: Bearer <oauth-token>

Effective access is the intersection between the token’s OAuth domains and the current permissions of the underlying user platform.

Attention

Anyone who obtains the token can use the granted access until it expires or is revoked. Keep it in the credential stock– not in workflow fields, expressions, execution data, log or exported configuration.

Choose the implementation platform

The server and the OAuth token must belong to the same platform deployment:

US

https://us.probo.com

EU

https://eu.probo.com

Self-hosted

https://<your-host>

Do not attach /api, a pathGraphQLor a tracking path. The node selects the pathAPIfor each operation.

Create an OAuth token

1. Log in to the deployment of the platform that contains the data.
2. Open the account menu and select OAuth tokens.
3. Select Create token.
4. Enter a name specific to the purpose, such as n8n production – compliance sync.
5. Select an expiration and only the fields required by the workflow.
6. Create and copy the token. the platform displays its value only once.

Create a separate token for each mediumThe separate tokens offer independent domains, expiration, audit history, and revocation limits.

___ZBT_I18N_RUNTIME_BLOCK_177__

Tokens created manually in the UI are standalone access tokens. They do not include a refresh token. Choose a expiration that matches your rotation policy and replace the token before it expires.

Select scopes

Resource scopes use two forms:

• v1:<resource>:read allows reading operations for that resource family.
• ___ZBT_I18N_RUNTIME_BLOCK_180__ allows both reading and writing operations for that family.

For example:

Workflow capability	Scope examples
Credential test and organizations	v1:iam:read for reading or v1:iam for writing
Citeste sau schimba riscurile	___ZBT_I18N_RUNTIME_BLOCK_182__ or v1:risk
Read or modify third parties	v1:third-party:read or v1:third-party
Citirea sau modificarea documentelor	v1:document:read or v1:document
Citirea sau schimbarea sarcinilor	v1:task:read or v1:task
Activation and management of the Trigger Platform	v1:webhook

Other families include asset, audit, control, privacy, access-review, itam, and compliance-page.

The acreditaren8 test requires authenticated identity so that it includes v1:iam:read or v1:iam even when the workflow mainly uses a different resource family.

Configure the n8n credential

1. Open a the platform node

   Add the platform or the platform Trigger to a workflow.

2. Create a the platform credential

   Open Credential and select Create New CredentialUse a name that identifies the implementation and environment, such as ___ZBT_I18N_RUNTIME_BLOCK_202__.

3. Configuration of the OAuth server and token

   Field	Value
   the platform Server	https://us.probo.com, https://eu.probo.com or the origin of the self-hosted implementation
   OAuth Token	Scoped OAuth token created on this implementation

4. Test the credential

   Select Testn8send a query ___ZBT_I18N_RUNTIME_BLOCK_205__ to:

   <Probo Server>/api/console/v1/graphql

   A successful test proves căn8npoate reaches implementation and that the token includes an IAM scope supported by the identity query.

5. Save and test a reading operation

   Save the credential, then run Organization → Get Many or another read-only operation before writing the test or activating a trigger.

When the credential is used

All platform nodes can reuse the credential:

Node or operation	Application made with the OAuth token
Dedicated the platform actions	ConsolaGraphQLAPIla /api/console/v1/graphql
Execute → Console API	Customized operation to /api/console/v1/graphql
Execute → Connect API	Customized operation to /api/connect/v1/graphql
the platform Trigger activation	Create, verify and delete a webhook subscription via the GraphQLAPI console
the platform Trigger event delivery	Do not send the OAuth token; the platform signs the delivery with the subscription signature secret

Updating or revoking the OAuth token does not invalidate a already delivered webhook signature.

Authorization model

Testing credentials does not prove that every workflow operation is authorized.

Accesul efectiv este intersecţia dintre:

1. The scope of resources assigned to the OAuth token.
2. The current member of the token user in the target organization.
3. User permission to read, create, update, publish, archive, delete or the requested special operation.

For example, a token can pass the accreditation test but fails Risk → Create when it only has v1:risk:read, or when its user cannot create risks in the selected organization. the Trigger platform requires both the v1:webhook domain and user permission to create and delete webhook subscriptions.

To reduce access:

• Allocate only the resources areas required for the workflow.
• Prefer the fields :read when the workflow does not write.
• Use a platform user with only members and required automation permissions.
• Separate workflows with substantially different privileged levels in different credentials and, where applicable, different platform identities.
• Remove the tokens before removing or disabling the user who created them.

Permission and membership changes apply to subsequent requests to the API; the token does not retain access that the user no longer has.

Expiration, rotation, and revocation

OAuth tokens created by the UI have an explicit expiration and no refresh tokens.n8n cannot extend or refresh them.

Rotate without interrupting scheduled workflows:

1. Create an OAuth replacement token on the same deployment with the required domains.
2. Replace the token in the credentialn8inexisting.
3. Credential testing and performing a representative reading operation.
4. Test authorized writing in a secure environment when the workflow writes data.
5. Active confirmation of trigger workflows can still check their subscriptions.
6. Revoke the old token under OAuth tokens.

Withdraw a token as soon as it is exposed, its workflow is withdrawn or its user should no longer be represented by automation. Withdrawal is not a break: requests using that token stop authentication and cannot be restored.

Self-hosted connectivity

For a self-hosted platform deployment, use the accessible source from each processn8nwhich runs a platform node, for example https://probo.internal.example.com.

• Resolve the hostname.
• Touch the server through the applicable network and firewall rules.
• Trust the server’s TLS certificate chain.
• Keep the header Authorization through any reverse proxy.

The credential test targets:

https://probo.internal.example.com/api/console/v1/graphql

The Trigger platform requires two-way connectivity.n8nmust reach the platform to manage the subscription, while the platform must reach the production webhook URL aln8nthrough HTTPS to deliver events.

Diagnose authentication failures

Symptom	Likely cause
Credential test cannot connect	Invalid server origin, DNS failure, SSL certificate, proxy or firewall
Credential test reports authentication error	Malformed, expired, revoked, or wrong-deployment token
Credential test reports insufficient scope	Keyword: ___ZBT_I18N_RUNTIME_BLOCK_221__ or ___ZBT_I18N_RUNTIME_BLOCK_222__
The test passes, but an operation is prohibited	Lack of resource scope, organization members, or user permission
Resource is not found	Wrong resource ID, wrong organization, or a resource hidden by the authorization limit
Run works for Console, but not for Connect	The operation is absent from thatAPIor the token does not authorize it
Trigger activation fails	v1:webhook, missing user permission, incorrect organization ID or invalid production webhook configurationn8n

Changing the carrier format does not correct an authorization failure after the authentication test has succeeded. Check the selected deployment, token expiration, assigned domains, organization and current user permissions.