oAuth2 Credentials HTTP Request "Invalid Login Attempt" after token refresh

I have a NetSuite Workflow that all of a sudden started getting a 400 Bad Request Invalid Login Attempt error on the 2nd HTTP Request (PATCH Invoice). The First http request in the workflow is a GET request to get the Invoice data and that works how it’s always been. Then the PATCH request after the GET throws the below error. In NetSuite I can see a successful log in and then a Failure with at first a “jti=[####].AccessTokenExpired” error and then on the next Invoice the same success then failure but with the error “jti=[####].MissingKey”.

I’m not sure how it can be successful for the Get request and fail a second later for the Patch request. Is this a bug or is there something I need to change? I had to re-authenticate the credentials/consent this morning like I’ve had to do every 7 days which is a whole other thing I’m trying to figure out a workaround for but that’s the only thing that I had done today when this started.

What is the error message (if any)?


"400 - {"type":"rfc url","title":"Bad Request","status":400,"o:errorDetails":[{"detail":"Invalid login attempt. For more details, see the Login Audit Trail in the NetSuite UI at Setup > Users/Roles > User Management > View Login Audit Trail.","o:errorCode":"INVALID_LOGIN"}]}",
"AxiosError: Request failed with status code 400 at settle (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/core/settle.js:19:12) at IncomingMessage.handleStreamEnd (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/adapters/http.js:589:11) at IncomingMessage.emit (node:events:529:35) at IncomingMessage.emit (node:domain:489:12) at endReadableNT (node:internal/streams/readable:1400:12) at processTicksAndRejections (node:internal/process/task_queues:82:21) at Axios.request (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/core/Axios.js:45:41) at processTicksAndRejections (node:internal/process/task_queues:95:5) at requestFn (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:561:33) at proxyRequestToAxios (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:564:26) at Object.request (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:1939:50) at Object.requestOAuth2 (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:992:12) at Object.requestOAuth2 (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:1947:20)",

Information on your n8n setup

  • n8n version: 1.29.1
  • Database (default: SQLite): ?
  • n8n EXECUTIONS_PROCESS setting (default: own, main): ?
  • Running n8n via: n8n cloud
  • Operating system: Mac OS 12.7.3 (21H1015)

It looks like your topic is missing some important information. Could you provide the following if applicable.

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

@Justin_B , if the token is indeed correct and used properly then perhaps there is a clock drift on the server making it expired prematurely when used subsequently? Could you check the time set on the server is accurate?

Thanks for the reply @ihortom,
I have no way to see that information within NetSuite but I don’t see anything that has changed within NetSuite that would have caused this. I can see that the “oAuth 2.0 Authorized Applications” still shows n8n as active. After this started yesterday, I revoked it’s access and then had the oAuth2 within n8n recreate it so it’s brand new but that didn’t fix this.

I still don’t understand how in the same workflow, one HTTP request node works find and then 2 nodes later the 2nd HTTP request node fails.

I can see in the NetSuite Login Audit Trail entries like these for each workflow execution:
1st login gets this error: jti=a-a.9de2ed9a-2007-4b6b-a50d-5a4bc625b14f_1710192727052.1710199147023 AccessTokenExpired
2nd login is successful to /services/rest/auth/oauth2/v1/token
3rd login is successful to GET the invoice details
4th login Fails with this error: jti=a-a.9de2ed9a-2007-4b6b-a50d-5a4bc625b14f_1710192727052.1710203150978 MissingKey

I’m going to try to create a new oAuth2 credentials to replace the current one and see if that some how fixes this.
Also, this has been working fine for the last 3 weeks since it went live.

The new Credentials did the same thing. I also created a new integration record in NetSuite to get new Client ID/Secret ID to check if that’s causing it and that didn’t help either.
I’m getting the exact same “MissingKey” error in the login audit trail and n8n error of Invalid Login Attempt after first being successful.

@ihortom Any other suggestions? or could this possibly be a bug?

@Justin_B , no, I have no other thoughts. I have never worked with NetSuite and my suggestion comes from my experience with other servers. If the clocks are not aligned and the token lifecycle is very short, the discrepancies in time between the communicating servers could cause premature token expiration.

Thanks @ihortom , That makes sense but I can’t figure out how it was working before and now all of a sudden it’s not without anything changing. And I don’t have a way within n8n’s credentials to set a time frame for the token to be available for.
Either way, the first request shows it’s an expired token which is then refreshed so why wouldn’t the 2nd request do the exact same. Instead it just throws an error that looks like the header authentication is missing a key.

Is there an n8n support on here that I could escalate to?

I’ve also tried setting up oAuth 1.0 credentials but I’m getting the below error when trying to connect that too.

OAuth Authorization Error

There was a problem generating the authorization URL
Request failed with status code 400

Yes, I can help you with that (done now). Hopefully, someone from n8n team attends to this thread soon.

1 Like

FYI - I made a copy of my workflow and re-did a lot of the steps and somehow it’s now working. Not sure what it was but it seems to have fixed it (for now).

Thank you for your assistance @ihortom

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.