[SSO Session Length] Allow For Longer Sessions

[souredoutlook]

Problem Statement

Daily users of Sentry that are members of organizations that have SSO configured are prompted to authenticate frequently, we cover this in our docs:

For individual organizations with single sign-on, we expire organization access after one day (20 hours).

We have received feedback from a number of individuals that this duration is too short. Take this thread for example, or more specifically this feedback about our service:

@getsentry thoughts on fixing the fact that I'm signed out every single day?

[...] we use SAML with all our services and Sentry is the only one that kicks off. You can verify that the user is still valid through the issued access/refresh token without having such a short-lived session.

For Sentry maintainers: this issue is also linked to an internal ticket that tracks various Zendesk tickets where configurable session duration for organizations with SSO has been requested.

Solution Brainstorm

In the past some solutions have been put forward:

Actually we use GSuite auth. This is pretty annoying and in Linear we poll the API once in a while to kick off if offboarded. Much better than constantly getting kicked out

Internally we discussed:

• Possibly extending the session duration to 7 days
• An organization level toggle for configuring session duration

This value is also configurable in self-hosted Sentry which has prompted some users to request this change in our SaaS offering.

We also discussed other services such as GitHub which require frequent authentication, and looking more broadly about feedback around both their service and ours.

┆Issue is synchronized with this Jira Improvement by Unito

[getsantry[bot]]

Routing to @getsentry/enterprise for triage, due by Tue Jan 17 2023 19:58:44 GMT+0000. ⏲️

[silent1mezzo]

I feel like 7 days makes the most amount of sense. It gets me through my work week without having to authenticate again.

[JoshFerge]

yes, maybe 7 days with a UI configuration to change it to 20 hrs for the security conscious? Also, how do the various providers handle persistent sessions? e.g. does google SSO have a mechanism for refreshing a session without having to re-login?

[souredoutlook]

@JoshFerge Google's OAuth platform provides refresh tokens with the access token. https://developers.google.com/identity/protocols/oauth2#5.-refresh-the-access-token,-if-necessary.

[dcramer]

Forget if it was in sentry or another project, but we would hammer SSO providers to re-validate sessions. Something like up to one-an-hour we'd check upstream to see if the client could still access the resources. To me that kind of thing is preferable, but there also might be some awful-lawyer-doesnt-understand-tech compliance regulations we're navigating for some customers?

[jorilallo]

With GSuite you can implement forever tokens with refresh tokens and in the background call Google's API with some throttling to check token validity (i.e. if the user has been offboarded). No reason to limit session length etc and provide more immediate matching of access to the Google Oauth access.

[dcramer]

https://github.com/getsentry/sentry/pull/48596 this is just duct tape atm

[bpartridge]

Being able to set this at an organization level beyond 7 days - indeed, indefinitely - would be incredibly useful. There are many small technology teams where personnel changes are rare enough (so it's more than feasible for offboarding to include explicitly removing a user from Sentry) but on-call incidents where team members may be logging in from e.g. infrequently used mobile devices are numerous.

If there's friction of waiting to reauthenticate on those devices (e.g. over Google SSO), those are vital seconds that may materially count against a team member's limited time to weigh in while traveling, between meetings, etc. - and this makes Sentry feel like the bottleneck slowing down the speed-of-thought during the incident. As Sentry's offerings expand to things like Replays where even less-technical team members may be weighing in on the business ramifications of the affected users' replays (and even more likely to do so from rarely-used mobile devices), this becomes even more significant - those users will be even less forgiving to the security rationale of why Sentry logged them out.

Of course, it will be important to document the caveats here, and help admins to not accidentally break any of their own regulatory requirements if they were to find the page to customize this. But for startups with increasing pressure to move quickly with smaller teams, this could materially further associate Sentry with the feeling of saving the day rather than the feeling of slowing down every triage process.

[getsantry[bot]]

Routing to @getsentry/product-owners-sign-in for triage ⏲️

[allusernamestakenexceptthis]

is there an ETA on this? or are there already any settings? because this is a hurdle to check errors. always have to login and use 2fa. it's more secure than many bank accounts.

[leedongwei]

@allusernamestakenexceptthis We're speccing out a refactor of the authentication pipeline now, but cannot promise an ETA.