# Keep session alive

**URL:** <https://discuss.pomerium.com/t/keep-session-alive/118>\
**Category:** Support\
**Created:** [May 20, 2022, 9:02am UTC](https://discuss.pomerium.com/t/keep-session-alive/118 "2022-05-20T09:02:30Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nicolas](https://avatars.discourse-cdn.com/v4/letter/n/67e7ee/32.png) [@Nicolas](https://discuss.pomerium.com/u/Nicolas)\
**Post date:** [May 20, 2022, 9:02am UTC](https://discuss.pomerium.com/t/keep-session-alive/118/1 "2022-05-20T09:02:30Z")

</div>

## Question?

I am looking for a way to extend Pomerium session automatically if the user is active.  
Currently, I am using the default cookie expiration: 14h. I would like to be able to close sooner the user session if the user is not active. I thought about reducing the cookie expiration to 1h but then the user has to login again every 1h.

Ideally, I would like to logout the user after 1h of inactivity or after a day. This would force the user to authentication again every day and also reduce the risk of session staying open if the user does not use the application.

Does Pomerium support such functionality ?

## What’s your environment like?

- Pomerium version: v0.14.2
- Linux container inside a Kubernetes cluster
- Traefik is used as Ingress controller
- Pomerium is used for forward auth from Traefik
- Keycloak is used as Identity Provider for Pomerium

## What’s your config.yaml?

```auto
shared_secret: XXXXX
address: :80
insecure_server: true
policy:
- from: https://myapp.external
  to: http://myapp.internal:8080
  allowed_domains:
  - mydomain.com
authenticate_service_url: https://pomerium-authenticate.external
cookie_secret: YYYYY
idp_client_id: keycloak-idp
idp_client_secret: ZZZZZ
idp_provider: oidc
idp_provider_url: https://keycloak.external
idp_qps: 0
authorize_service_url: http://pomerium-authorize.internal
forward_auth_url: http://pomerium-proxy.internal
databroker_service_url: http://pomerium-cache.internal
databroker_storage_type: memory

```

I am also open to other solutions that could logout the user automatically after a period of inactivity.

---

<div class="post-metadata">

**Author:** ![bobby](https://yyz1.discourse-cdn.com/flex031/user_avatar/discuss.pomerium.com/bobby/32/1_2.png) [@bobby](https://discuss.pomerium.com/u/bobby)\
**Post date:** [July 14, 2022, 10:15pm UTC](https://discuss.pomerium.com/t/keep-session-alive/118/2 "2022-07-14T22:15:33Z")

</div>

Thanks for the post @Nicolas . In short, not today but this should be doable and is a reasonable feature request.

> [@Nicolas](#):
>
> Currently, I am using the default cookie expiration: 14h. I would like to be able to close sooner the user session if the user is not active. I thought about reducing the cookie expiration to 1h but then the user has to login again every 1h.

That is correct. Currently, [Expiration](https://www.pomerium.com/docs/reference/expiration) of a user’s session sets the max lifetime of not only the cookie (stored locally in a clients browser), but the maximum duration that Pomerium will attempt to refresh and keep valid a given user’s session.

> [@Nicolas](#):
>
> Ideally, I would like to logout the user after 1h of inactivity or after a day. This would force the user to authentication again every day and also reduce the risk of session staying open if the user does not use the application.
> 
> Does Pomerium support such functionality ?

We discussed the functionally today as a team today and it should be possible.

Just to clarify, would your ideal functionality be that today’s `Expiration` act as an absolute maximum a user session would be valid for (e.g. 2 weeks) and a new setting `Expires_after_inactivity` (or something better named 😉 ) dictate how long an inactive session be good for (e.g. expires after 8 hours of no user interaction)?

If that’s correct, to make sure that we accurately capture your user stories, do you mind following up with a [feature request](https://github.com/pomerium/pomerium/issues/new?assignees=&labels=&template=feature_request.md) and link back to this issue.

---

<div class="post-metadata">

**Author:** ![bobby](https://yyz1.discourse-cdn.com/flex031/user_avatar/discuss.pomerium.com/bobby/32/1_2.png) [@bobby](https://discuss.pomerium.com/u/bobby)\
**Post date:** [July 18, 2022, 4:42pm UTC](https://discuss.pomerium.com/t/keep-session-alive/118/3 "2022-07-18T16:42:41Z")

</div>

@Nicolas – An earlier request that is very similar.

> <https://github.com/pomerium/pomerium/issues/1250>
>
> \*\*Is your feature request related to a problem? Please describe.\*\*
> 
> My session… (authenticated session) should expire after I'm idle (I left the keyboard, got lunch, stuck talking to a chatty coworker) for an X amount of time. If I'm actively working, I do not want/need my session to expire as I should be considered an active user.
> 
> \*\*Describe the solution you'd like\*\*
> A configurable time option that can ensure active users aren't expired, but inactive users need to reauthenticate after whatever amount of time you've configured in your policy.
> 
> cc: @mustache84

---

<div class="post-metadata">

**Author:** ![Nicolas](https://avatars.discourse-cdn.com/v4/letter/n/67e7ee/32.png) [@Nicolas](https://discuss.pomerium.com/u/Nicolas)\
**Post date:** [August 7, 2022, 12:01pm UTC](https://discuss.pomerium.com/t/keep-session-alive/118/4 "2022-08-07T12:01:21Z")

</div>

Thanks @bobby for the answer, I am checking with my Product Managers to define our expected behavior. I feel like your suggestion with an absolute expiration and a inactivity expiration could work out.

I assume that from Pomerium point of view, inactivity means that no call to a protected service is made. Am I correct ?  
If this is the case, and we would like to keep the session alive even if the user is only active in the UI without any backend calls, I imagine that having a “keep alive” backend call triggered on schedule would be enough to refresh the Pomerium session. Could you confirm ?

When the session is refreshed, will the cookie be refreshed transparently for the end user ?

I’ll update the feature request as soon as we define our full expected behavior.

---

<div class="post-metadata">

**Author:** ![bobby](https://yyz1.discourse-cdn.com/flex031/user_avatar/discuss.pomerium.com/bobby/32/1_2.png) [@bobby](https://discuss.pomerium.com/u/bobby)\
**Post date:** [August 7, 2022, 8:33pm UTC](https://discuss.pomerium.com/t/keep-session-alive/118/5 "2022-08-07T20:33:50Z")

</div>

> Thanks @bobby for the answer, I am checking with my Product Managers to define our expected behavior

Sounds good.

> I assume that from Pomerium point of view, inactivity means that no call to a protected service is made. Am I correct ?

Yes.

> If this is the case, and we would like to keep the session alive even if the user is only active in the UI without any backend calls, I imagine that having a “keep alive” backend call triggered on schedule would be enough to refresh the Pomerium session. Could you confirm ?

Yes, that should do the trick. As long as something is “polling” a the pomerium protected backend, the session should be kept alive if we implemented this capability.

> When the session is refreshed, will the cookie be refreshed transparently for the end user ?

That’s a trickier question. If we implemented keep-alive, I would argue that session cookies could be much longer lived without compromising any security (indeed, I think it would be totally fine to set no expiration, or a very long out expiration on the session cookie itself) in this model since activity is kept more reliably by the backend system.

> I’ll update the feature request as soon as we define our full expected behavior.

👍

---

<div class="post-metadata">

**Author:** ![alexrudd](https://avatars.discourse-cdn.com/v4/letter/a/bbce88/32.png) [@alexrudd](https://discuss.pomerium.com/u/alexrudd)\
**Post date:** [August 23, 2022, 3:07pm UTC](https://discuss.pomerium.com/t/keep-session-alive/118/6 "2022-08-23T15:07:51Z")

</div>

I’d also be interested in such a feature, allowing us to push the default cookie expiration to a week or two.

Our old auth solution simply returned 403s, which were easy to catch in client code. It’s proving more difficult than expected to catch pomerium’s redirect attempts using the JavaScript fetch() API, especially when CORS on the IDP is involved. Not pomerium’s fault (we need to learn front-end better), but this feature would help our transition.
