EventBridge API Destinations - Created Auth0 tokens are already expired

1

I think there is an issue with how auth tokens are being handled/supplied. When my event bus receives an event and my rule passes the event into my API Destination my API rejects the communication with a 403. After looking at the bearer token jwt, the token creation date iat value is set to the time the API Destination & connection was authorized, even hours later.

The concept of bearer tokens are to be short lived and I would expect that the API Destination would request a new bearer token each time it is invoked.

example:

  1. I created an API Destination w/ a valid connection on Friday Apr 1 at 7am.
  2. My bearer tokens have a 60 min TTL
  3. My event bus receives a valid event on Friday Apr 1 at 730am
  4. A rule sends the event into my API Destination which uses its token send the event to my API and it is successful
  5. My event bus receives another valid event on Friday Apr 1 at 830am
  6. A rule sends the event into my API Destination which uses its token send the event to my API and it fails.

For step 4 & 6 above the token is identical. I would have expected the API destination to call the auth url with its credentials to get a new bearer token

From what I can tell the JWT created time will always be this date/time here and I have been fully unable to get a valid & unexpired JWT created anytime after an hour from launching the API Destination.

Two supporting images here

asked 2 years ago869 views
1 Answer
0

Hello, and thanks for reaching out!

So, the key things going on with how the auth token is being handled has to do with:

  • The lack of an auto-refresh mechanism upon each invocation with regard to the auth tokens being used by the API Destination Connector and
  • The HTTP 403 response received from your API for the requests using the expired token.

EventBridge documentation will point out that among others, no 4XX error codes other than 429 are retried.

However, this has a slight caveat to it, in that in the event of an expired auth token, an HTTP response of 401 or 407 will result in a retry process in which the token will be refreshed.

UPDATE: Information regarding 401 and 407 responses refreshing OAUTH tokens has now been updated in AWS Documentation

With this in mind, you can modify the response given by your API to either 401 or 407 instead of 403 in the event of an expired auth token, and this should enable the token refresh process.

AWS
SUPPORT ENGINEER
answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions