Better support for Refresh/Access Tokens

The idea is:

Provide better support for refresh tokens, which are becoming increasingly common. I use them with Amazon’s Selling Partner API. Also see this thread:

Part 1:

Create two new credential types: a “Refresh Token” and an “Access Token from Refresh Token”. Allow the Access token to be updated using the N8N API via a PATCH operation.

As an optional part of the schema for the Access token credential, allow the user to reference a “Refresh Token” credential so there’s an enforceable linkage.

As an additional option if the refresh token is provided, let the user enter the URL where the refresh token is exchanged for the access token. If that option is selected, before saving validate that an access token is received when the refresh token is presented at that URL.

Part 2:

Create a module (in the N8N events and actions section) which allows you to update the Access token. This is for APIs where the refresh/access exchange happens in some non-standard way. For example, Amazon Selling Partner API has “Restricted Access” tokens which have very limited scope and require you to provide a whole bunch of extra info in the exchange request. Presumably that module will be used at the end of a small workflow that requests the access token.

Part 3:

Update the HTTP module with support for the Access Token type.

If a request is made using an access token and

  1. The response is that the access token has expired, and
  2. The token is fully set up the access token with the correct refresh token and URL,

then automagically request a new access token & retry the request.

I think it would be beneficial to add this because:

It makes N8N even more better than Make.com. :slight_smile:

Any resources to support this?

Amazon SP-API:
Regular tokens: Connecting to the Selling Partner API
Restricted Tokens: Tokens API v2021-03-01 reference

Are you willing to work on this?

As I always say, nobody wants me working on code that someone else will use in production.

You have just described the regular OAuth 2.0 flow… that is handled with the OAuth2 API credential type (or any OAuth 2.0 service specific ones). Because OAuth2 is all about access and refresh tokens :slight_smile:

1 Like

Whelp, glad to help reinvent the wheel! :rofl:

I think one difference in my approach is letting someone set the Access key using a patch API call or an N8N module. That’d make sense for processes that don’t follow the normal Oauth2 paradigm, like SP-API’s restricted tokens.