authenticate: allow manual refresh about pomerium

[desimone]

@victornoel

Just to confirm -- as this may have chanced since the initial issue was file -- group membership (or lack there of) will be updated along with the session for most identity providers. The session expiration is usually set by the upstream identity provider (usually ~1-3 hours) and pomerium tries to renew the token at roughly half that (COOKIE_REFRESH defaults to 30 minutes). That said, you could shorten the refresh period and depending on how many users you are supporting it could be fine.

It's a tradeoff between accidentally DDOS'ing ourselves and the identity provider (which have strict query limits ) and making sure the user is not carrying stale credentials.

[victornoel]

@desimone Thanks for the explanation.

When I wrote this issue, I was (maybe incorrectly) expecting that adding a user to a group would be taken into account without any delay, while it seemed perfectly normal that removing a user for a group would take some time to be taken into account.
I see from your explanation that both are handled in the same way.

I'm not sure what is possible to improve the user experience though… I worry that if one of my user tells me that he needs to access an app and that I add him to a group, then he has to wait at most 15mn and be unhappy :)

[desimone]

@victornoel

It's not an ideal situation. I'd like to have a "recheck my access" button, especially on the unauthorized access user page.

I looked (indeed, it's still commented out in the code) at adding a refresh endpoint which would force a user/group session update. But without a backoff interval / rate limiting, a user ( either accidentally or maliciously) could DOS the identity provider and cause you to unexpectedly hit your IdP's QPS limits.

The problem is tracking user state (in this case, how much has bob@company been hitting that refresh button) is challenging because we don't have a backend datastore that can be queried across potentially many pomerium instances. State is currently tracked in the user session.

For the purpose of access, If the user clears their session, no big deal, we require a re-authentication.
However, tracking state of how often a user has hit refresh gets tricky because if they clear their session, we no longer know the last time they hit refresh and we can't rate limit effectively.

A option could be to allow refreshing for users that have been logged in for at least some interval (say ~5 minutes) and also track last refresh timestamp in the session.

So basically ...

IF (user-state is at least X minutes old) AND (user-state.last-refresh is null OR user-state.last-refresh >= X minutes ago)
ALLOW REFRESH
ELSE
DENY REFRESH

Could work?