search

OpenIDC / mod_auth_openidc

OpenID Certified™ OpenID Connect Relying Party implementation for Apache HTTP Server 2.x
Apache License 2.0
990 stars 327 forks source link

Access seems to inexplicably be revoked after 5 Minutes #160

Closed wobenshain closed 8 years ago

wobenshain commented 8 years ago

The JWT has a timeout of 10 hours and the state (reference) cookie still exists. I even tried having the information stored in the cookie instead of the apache server but it always expires after 5 minutes. None of the timeouts that I've tried altering seem to have changed this. I'm assuming I'm missing something but I've got no idea what.

zandbelt commented 8 years ago

Could this be the inactivity timeout defined here: https://github.com/pingidentity/mod_auth_openidc/blob/master/auth_openidc.conf#L393 which means that the session is killed because no user interaction occurred for 5 minutes? If so you may increase that timeout to achieve different behaviour.

Remember, the JWT timeout is not relevant unless OIDCSessionMaxDuration is set to 0, see: https://github.com/pingidentity/mod_auth_openidc/blob/master/auth_openidc.conf#L536

wobenshain commented 8 years ago

@zandbelt That seems to be the setting I'm looking for, yes. Is it possible to disable the Inactivity timeout entirely? Ideally we'd like to use this to handle being logged in for a session and/or indefinitely. We're not really looking to force the user to log back in at predefined intervals. However, it looks like all the options are set up using the assumption that the developer will want to be extremely restrictive.

zandbelt commented 8 years ago

The default options are relatively secure to protect people from shooting themself in the foot; you cannot disable timeouts entirely (and completely ditch security); you can set it to very insecure, very long intervals that are equal or larger than OIDCSessionMaxDuration.

wobenshain commented 8 years ago

@zandbelt Thank you for the answer. But is there a functional difference between checking "Stay logged in" on Google and not letting the token time out? I ask because I certainly wouldn't call the former "completely [ditching] security", and what I've read on Auth0 doesn't suggest there should be a difference.

zandbelt commented 8 years ago

Google uses advanced contextual techniques to make sure that the user operating the browser is still the same user that started the session which makes it easier/more-secure to maintain long-lasting sessions. This module doesn't have those advanced techniques.

Instead it can actually rely on Google's (and other IDPs in general) security by redirecting the user to Google after an application session timeout. If the Google session is still valid (determined using their advanced techniques), the user won't be prompted for a password but will just be logged in again to mod_auth_openidc -> SSO. This is how applications leverage the authentication specialization of IDPs in SSO flows without compromising security.

In general the RP should rely on an OP for authenticating the user and try to make their own decisions as little as possible (without sacrificing usability), this is no different.