I’m using the OAuth2 plugin on my hosted site, so my co-workers can log in with Box. The main goal is to avoid having yet another credential to manage. Part of that is a requirement that if someone leaves and we deactivate their Box account, we don’t want them to be able to access our Discourse site anymore. I looked around the admin area but didn’t see a setting to force re-authentication after N days… is there something like that and maybe I’m just missing it? If not, then please consider this a feature request. Without it, I’ll have to add Discourse to our checklist of things to do when employees leave, which is getting quite long…
AI-generated summary
The discussion revolves around forcing OAuth2 re-authentication after a certain period (N days) in a Discourse site. aviflax wants to implement this feature to automatically revoke access to former employees who have been deactivated from the company’s Box account.
Falco suggests that the cookie expiration mechanism could help, but aviflax points out that this may not be sufficient, especially considering Chrome’s behavior. Falco mentions that a setting for this feature is planned but not yet available.
aviflax proposes an alternative approach: tracking the last login time and forcing re-authentication after a configurable period. This method is used by Google Apps and could provide a smoother experience for users.
pfaffman suggests using the Discourse API to deactivate users or force a browser refresh, but aviflax explains that this is not feasible in their current manual deactivation process.
Seems somewhat related to this thread: Session Timeout.
The cookie having Expires: Session will re-auth on the SSO endpoint every time the browser is closed and reopened*. I think this will sort it.
* Except sneaky chrome
@Falco thanks for the quick reply!
I’m not sure that applies in my case, as I’m not sure I’m using SSO? I’m using OAuth2. They’re different, right?
Even if I am using SSO, lots of folks use Chrome so unfortunately relying on that mechanism wouldn’t suffice.
The mechanism will work independently of authentication method. Just said SSO to illustrate my use case.
Ah, OK, thanks for clarifying!
So is that header sent by default in all configurations? Or do I need to do something to turn it on?
And… is there anything I can do about Chrome?
It isn’t possible atm.
I’m looking to create the setting sometime in the next month.
And Chrome keeps the app running on the background on desktop, but nothing we can do about it. Except using a fixed time (like 30 minutes) but that’s bad for other reasons.
Ah, I see — thanks for clarifying!
An alternative approach that should work on all browsers and might be less annoying for users would be to keep track of the last time a user logged in, and on every page access compute how long ago that was, and if it’s greater than N {days,hours}, then force them to re-authenticate.
And of course N should be configurable; security and user annoyance would both have an inverse relationship to the size of the value.
Google does this with my Google Apps accounts (with 2FA enabled) — they force me to re-authenticate once a month, but it’s pretty smooth.
If what you want is for people that you have deactivated to be, well, deactivated, you could deactivate their Discourse account or force browser refresh via the API. It probably wouldn’t be that hard to add such a call to your deactivation script at Box.
Thanks, but we’re not using a script. We’re manually deactivating the users when they leave the company. My hope is that we can set things up such that we wouldn’t have to do anything else; simply by dint of the Box account being deactivated, a user would lose their access to Discourse shortly thereafter.