[Feature request] Handle custom JWT expiration setting (eg 5 minutes) about cloudfront-authorization-at-edge

[ottokruse]

Might make a parameter out of that 10 min thing, instead of hardcoding it like this.

[rpattcorner]

I'm also working with the AWS Support crew on this -- after reiterating how auth@edge works, their engineer suggested:

Hopefully this helps clear the doubts of the occurrence you are seeing. It also confirms what you said that because of the session duration of the cookies generated by the Lambda@Edge function, the access token duration you set in Cognito is basically not taking effect even though Cognito is actually retiring the token.

If I understand that right, there might be two issues, not just one.

1. The original issue ... a problem in the 1.2.1 version of a@e (unknown for 1.3 at this time) that prevents it from dealing with a cognito that is custom-configured for a timeout.
2. Another different but related issue suggested by the quote above ... that the cookie generated by a@e does not yet respect the possibly reduced (or extended) values in Cognito client

I wonder how many of these issues will be less of an issue with the 1.3 version of a@e, possibly if we bring the cognito user pool out of the framework and into the calling cloudformation. Ideas welcome and I'll start to look at that once time permits.

[ottokruse]

5 mins timeout for the tokens, that is not gonna work with this solution, because auth@edge is currently coded to refresh tokens when they would expire in the next 10 mins. This is to prevent the tokens from becoming expired, instead of waiting for that to happen first.

cloudfront-authorization-at-edge/src/lambda-edge/check-auth/index.ts

Lines 30 to 32 in 97788d8

	// If the ID token has expired or expires in less than 10 minutes and there is a refreshToken: refresh tokens
	// This is done by redirecting the user to the refresh endpoint
	// After the tokens are refreshed the user is redirected back here (probably without even noticing this double redirect)

So then you'd get into a loop situation, where tokens would be refreshed always. This might lead to unexpected errors, as the one you're seeing.

Do you really need 5 mins? What is the idea there?

[rpattcorner]

Sure. It's less of a problem than it looks. The idea was that in testing refresh scenarios it's important to get a short turn-around time. Anything better than an hour is ... better than an hour! So 12 minutes would do nearly as well as 5. And a parameter wouldn't hurt.

[lestephane]

I experienced the infinite loop as well after switching id tokens and access tokens to 5 minutes during testing. I would also expect the hardcoded 10 min to be configurable (all the way down to 1 min, because I feel lucky with worldwide, cross-region clock synchronization :) ).

[ottokruse]

I would also expect the hardcoded 10 min to be configurable (all the way down to 1 min)

Do send a PR for it if you'd like to get hands dirty.

[ottokruse]

In #184 it was implemented that "Refreshing of tokens is no longer performed ahead of time, but rather now "lazily" when needed."

This works better with short JWT expiration.