Persistent Authentication Issue with Google Document AI (ACCESS_TOKEN_TYPE_UNSUPPORTED) in n8n

Describe the problem/error/question

Hello everyone,
I’m encountering a persistent issue when trying to connect n8n to Google Document AI, despite numerous troubleshooting attempts. I’m reaching out to the community for any help or suggestions.
I’m trying to integrate Google Document AI into an n8n workflow using a Service Account. The initial connection test for the service account in n8n always succeeds: n8n indicates that the connection is “OK”.
However, as soon as I execute the workflow and the “Google Document AI - Structure” node attempts to process a document, I get an authorization error. I have meticulously checked the IAM roles for the service account, enabled the Document AI API, and ensured that the JSON key file for the service account is correctly pasted and unaltered.
My service account ( @.iam.gserviceaccount.com ) has the following IAM roles:

  • Document AI Administrator (beta)
  • Document AI API User (beta)
  • Document AI Editor (beta)
  • Document AI Viewer (beta)
  • Storage Object Admin (for Google Cloud Storage access).
    Despite these seemingly adequate roles, the error persists and points to an issue with the authentication token itself.
    The key point is ACCESS_TOKEN_TYPE_UNSUPPORTED , which suggests that the type of OAuth 2.0 access token being generated is not what the Document AI API expects, even though the service account credentials are initially accepted by n8n.
    I tried multiple hints from Gemini or n8n AI. All failed. I added scopes, regenerated my JSON, still get an initial connection “SUCCESS”.
    Hope someone can help me - Thank you!!

:slight_smile:

What is the error message (if any)?

Authorization failed - please check your credentials

Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See Integrating Google Sign-In into your web app  |  Web guides  |  Google for Developers .

Error details

From HTTP Request
Error code

401

Full message

401 - “{\n “error”: {\n “code”: 401,\n “message”: “Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.\\”,\\n “status”: “UNAUTHENTICATED”,\n “details”: [\n {\n “@type”: “type.googleapis.com/google.rpc.ErrorInfo”,\n “reason”: “ACCESS_TOKEN_TYPE_UNSUPPORTED”,\n “metadata”: {\n “service”: “documentai.googleapis.com”,\n “method”: “google.cloud.documentai.v1.DocumentProcessorService.ProcessDocument”\n }\n }\n ]\n }\n}\n”

{
“headers”: {
“accept”: “application/json,text/html,application/xhtml+xml,application/xml,text/;q=0.9, image/;q=0.8, /;q=0.7”
},
“method”: “POST”,
“uri”: “https://hidden-documentai.googleapis.com/v1/projects/Hidden/locations/hidden/processors/Hidden:process”,
“gzip”: true,
“rejectUnauthorized”: true,
“followRedirect”: true,
“resolveWithFullResponse”: true,
“sendCredentialsOnCrossOriginRedirect”: false,
“followAllRedirects”: true,
“timeout”: 300000,
“encoding”: null,
“json”: false,
“useStream”: true
}

Please share your workflow

Share the output returned by the last node

last node is only a PDF import using postman

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

Hi Benjamin,

Thanks for your reply.
I recreated a service account + new JSON key but don’t really see how to change the credential type as this seems to be always the same. Also I see the OAuth2.0 is activated, so not sure what’s going wrong unfortunately.

welcome to the n8n community @GauthB
I’ve seen people solve this by isolating Document AI in a dedicated service (Cloud Run/Functions) and having n8n hit it via webhook. Since n8n handles Service Accounts well in the HTTP node, offloading the auth and processing to a microservice makes things way more stable. It gets around node-specific limitations and makes managing service account keys and retry logic much easier.