[Feature request] Handle custom JWT expiration setting (eg 5 minutes)

[rpattcorner]

Using semantic version 1.2.1

Doing some timeout work and believe there might be an issue between auth@edge and the (very) new AWS feature to set a custom value on token expiration, documented here.

We start with a working angular SPA and default values. Verify operation and log out.

Now we change the identity and access tokens to 5 minutes and save:

On relogin we get the cognito email/password challenge, and then:

So that's not encouraging. We reset the timeouts to 60m and can log in fine with the "try again".

We can then reset the cognito to 5m but it's ineffective for testing (does not time out after 5m), probably because the app already has the 60m cookie.

Thoughts?

[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?

[ottokruse]

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

[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.