This may sound like a very trivial doubt, but I need some help here.
I have set up Application load balancer with OIDC authentication. After logging into my application, using chrome developer tool I looked into the client application cookie. Found that AWSELBAuthSessionCookie-0 and AWSELBAuthSessionCookie-1 have an expiry 2070-10-04T05:02:12.122Z which is almost 50 years from now. Since the ALB isn't forwarding this cookie to my application (EC2) which resides behind the ALB, I am unable to reset the cookie's expiration. I am using Flask to read the headers. Any leads to reduce the AWSELBAuthSessionCookie's expiry will be helpful.
I too have the same question, in my case it is being set to Expires=Sat, 29 Aug 2071 22:16:30 GMT. And I am unsure, even when I have set the Session timeout to 14400 seconds which is about 4 hours in the ALB authenticate rule.
It is quite unexplainable as to why this large expiry time would be set despite an explicit smaller value.
quite an old question already but here are my 2 cents:
invalidating a cookie is somehow just a set-cookie with an expired date, so I don't think you need to be able to read the cookie from the request to invalidate it. I have not tried but I would just do something like
Set-Cookie "AWSELBAuthSessionCookie-0=deleted;path=/;expires=Thu, 01 Jan 1970 00:00:00 GMT;"
for the 2nd point (from @codematix), to logout you need to invalidate the auth cookie AND to redirect the user the logout page configured in your IDP (probably to also invalidate the tokens, otherwise the ALB would just revalidate the tokens and re-create a session). See https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#authentication-logout-timeout
I think you are confusing the ALB session (JSESSIONID cookie if I recall correctly) with the auth session cookie here.
Once again I am no time to validate this but hope that helps :)